GPT-5.2 vs Claude Opus 4.5、なぜ「伝わる」感覚が違うのか【設計思想から比較】 前回の記事でCodex vs Claude Codeの比較を書きました。内容をもう少し深掘りしたくなったので、普段業務で両方を使用している私が、今回は「設計思想の違い」という観点から掘り下げてみます。 Claudeが選ばれる本当の理由 前回、エコシステムの成熟度でClaudeが優位という話をしました。MCPサポートの充実、10,000以上のプラグイン対応など。 ただ、MCP、サブエージェント、スキル、フック、リワインドなど、Claude発の機能は現状ではCodexでも使えるものが多くなっています。本当にエコシステムが主要な理由でしょうか。 私がClaudeを使い続けている理由は、もっと単純なところにあると思っています。話してて伝わりやすい。 同じ質問に対する回答の違い 「このコードはUI

静的なWebサイトを生成するJavaScriptフレームワーク「Astro」を開発するAstro Technology Companyは、CDNサービス大手のCloudflareによる買収を発表しました。 We are joining Cloudflare!https://t.co/pZXCJcRxgA — Astro (@astrodotbuild) January 16, 2026 Astroはさまざまなフレームワークに対応したサイトジェネレータ Astroは、ReactやVue、Svelte、Alpine.js、TypeScriptなどのさまざまなフレームワークやライブラリに対応したオープンソースの静的サイトジェネレータです。 ビルド時にWebサイト全体のHTMLが生成され、しかもそのHTMLには全くJavaScriptが含まれないか、もしくはWebブラウザ上での動作に必要な最小限の

はじめに前職で技術顧問として そーだいさん にJOINしていただいていた際、私はデータベース設計から仕事の進め方相談まで、本当にお世話になりました。 そーだいさんは「ガタイも(物理的に)声も大きくて、ちょっと圧倒されるな……！」というものでしたが、実際にお話ししてみると、その中身は驚くほど優しく、そして本当にロジカルで誠実な方でした。 その圧倒的な「言語化能力」で、技術的な課題はもちろん、エンジニアとしての振る舞いや問題解決の考え方を、誰にでもわかる言葉で解きほぐしてくれます。 今回は、私が定期的に読み返し、1on1などの場でも「まずこれを読んで！」と周囲に布教している、そーだいさんの発信をいくつか紹介したいと思います。 1. 仕事を進めるうえでのマインドセット1-1. Howだけ考えると複雑さを導入して仕事が増える 「偽の進捗」の連鎖によるリソース枯渇の防止 手段に没頭して手順書の保守や

2025年は色々ありすぎた年だった。人生が進みすぎた。 学業 3月に筑波大学を卒業した。2019年に入学して2回留年して、やっと卒業できた。 自分は昔から本当に勉強ができなくて、高校生の時は大して頭のよくない学校で学年でビリから5番目くらいだったから、6年かかったとはいえ割とまともな大学をちゃんと卒業できたってのは本当に嬉しい。 卒論の出来は本当に悪くて「えっこれでいいの？」ってくらい酷かった。LadybirdブラウザのJavaScript処理系であるLibJSに、可能な限りオーバーヘッドが少なくなるようにGCの動作をトレースするinstrumentationを実装して性能を評価する、みたいなやつをやった。これは実際にはJava向けの既存の手法をほぼそのまま実装しただけのやつなので研究としては普通にめっちゃしょぼかったし、性能評価も「それはそうですよね」という感じだった。 ただ、他の人のや

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

デンソーは、エンジニアの暗黙知を蓄積し共有するためのナレッジマネジメント基盤の開発を進めている。文書や音声に含まれる暗黙知をAI（人工知能）技術で抽出し、組織全体で検索可能にすることで設計力・開発力を高めるのが目的だ。開発を支援する富士ソフトが2025年11月28日に発表した。 デンソーが開発しているのは、エンジニアの暗黙知をデジタルデータとして蓄積・共有するためのナレッジマネジメント基盤（図1）。経験や判断の勘所を組織全体で活用できる知識として蓄積・整理し、設計力・開発力を高めるのが目的だ。 35の国と地域で事業を展開するなか、海外拠点では日本以上に人材の流動性が高く、限られた在籍期間の中で、エンジニアが持つ知識やノウハウをいかに組織に残すかが課題になってきたほか、熟練者の退職や異動によって知見が失われるリスクも顕在化していた。 開発中のナレッジマネジメント基盤では、エンジニアが蓄積して

この記事はLivetoon Tech Advent Calendar 2025の17日目の記事です。 本日はCTOの長嶋が、技術ではなくポエムを書きます。 毎回技術ネタ書いてると尽きるので・・・。 宣伝 今回のアドベントカレンダーでは、LivetoonのAIキャラクターアプリのkaiwaに関わるエンジニアが、アプリの話からLLM・合成音声・インフラ監視・GPU・OSSまで、幅広くアドベントカレンダーとして書いて行く予定です。 ぜひkaiwa使ってみてください。 この問いについて 「リーダーは技術者であるべきか」 テック業界で古今東西、繰り返し議論されてきたテーマだ。 技術がわかる人間がトップに立つべきか、それとも経営のプロに任せるべきか。 スティーブ・ジョブズはエンジニアではなかったが、プロダクトへの執着は誰よりも強かった。 一方でGoogleのラリー・ペイジやFacebookのザッカーバ

はじめに 「今年読んで良かった本」という記事を書こうとしている自分に、ふと気づく。また書くのか。毎年書いている。誰に頼まれたわけでもないのに、12月になると決まってこの作業を始めてしまう。習慣なのか、義務感なのか、それとも単なる自己顕示欲なのか。たぶん、全部だ。 100冊近く読んだ、と書こうとして手が止まる。この数字を出した瞬間、どこかで「すごいですね」と言われたい自分がいる。同時に、「いや、冊数なんて意味ないですから」と予防線を張りたがっている自分もいる。めんどくさい人間だ。でも正直に言えば、100冊読んだことより、1冊を血肉にできた人のほうがよほど偉いと本気で思っている。思っているのに、冊数を書いてしまう。そういう矛盾を抱えたまま、この文章を書いている。 AIに聞けば答えは返ってくる。2025年はそういう年だった。コードを書いてもらい、設計を相談し、ドキュメントを要約させた。便利だ。本

最近、1on1で同じ話を何度かしたので、ここに整理して残しておく。 生成AI・LLMが当たり前になりつつある今、「これから自分のキャリアをどう築けばいいかわからない」という相談を受けることが増えた。 新卒から自分と同世代*1まで、悩みの種類は違っても不安の根っこは似ている。 そのときにセットで話すことが多いのが、能力の伸ばし方とキャリアの積み上げ方だ。 能力の成長ステップは、こちらの資料に詳しくまとめている。 speakerdeck.com この記事では、主にキャリアをどう築くか、に絞って書く。 キャリアの築き方：土台を広げ、実績を積む キャリアは、積み木を積み上げていくようなものだ。 細く高く積むと、ちょっとした揺れで簡単に崩れる。たとえば、一時的な特需に合わせて実績の高さだけを優先して積むと、環境が変わった瞬間に吹き飛ぶ。 だからこそ重要なのは、土台（基礎）を広く、強くすることだ。 土

ワートリの29巻を読みました。 ワールドトリガー 29 (ジャンプコミックスDIGITAL) 最初にお断りしておきたいのですが、この記事には、先日発売された「ワールドトリガー」の29巻のネタバレが豊富に含まれます。 ワートリ読者の方で、まだ29巻をお読みでない方は、まず何も言わずに29巻をポチって、しばらく鬼リピしてからこの記事を読まれることをお勧めします。 大丈夫、特に何も言われなくても勝手に鬼リピしたくなると思います。30回くらいは。 この記事で書きたいことは、大体以下のようなことです。 ・ワートリの面白さの中核って、「答え合わせ」の面白さだと思うんです ・キャラクターひとりひとりの「考察」「考え方」「他者への評価」「対話・駆け引き」の描写が解像度高過ぎて、自分のイメージとのすりあわせがはかどり過ぎる ・「こういう状況で、このキャラならどう考えるか」という「答え合わせ」と「キャラクター

2025-11-23 TSKaigi Hokuriku 2025

僕は「越境しよう」と言うやつが嫌いだ。 越境したがる人に限って自分の役割をきちんと達成できていないことが多い。まずは自分に期待されている役割を100%、120%、全うすること。これが一番前提にあるべきだ。 そもそも越境はしたくてするものでも、期待されてするものでもない。目的から逆算してアクションした結果として「越境してしまう」ものなのだ。越境すること自体を目的にするな。解決したい課題、目指したい理想状態、必要なアクションを整理することが最優先で、その結果越境しなくても良いならそれで良い。 というか越境なんてしなくてもいいものだ。越境せずに組織がまわるならそれが一番良い。みんながみんな自分の得意なことだけやっていればうまく進んでいくというのが理想的な環境ではないか。それができないから渋々越境して得意ではないことも頑張っていこうねということではないのか。越境を推進する前に、越境なんてしなくても

Discover and participate in AWS workshops and GameDays

TOP ニュース オープンソースの大規模3D都市モデル生成技術「Skyfall-GS」発表！　衛星写真とAIのみで建物の側面や地上レベルのディテールを補完し、リアルタイムで3Dモデルを生成 2025/10/30 オープンソースの大規模3D都市モデル生成技術「Skyfall-GS」発表！　衛星写真とAIのみで建物の側面や地上レベルのディテールを補完し、リアルタイムで3Dモデルを生成 AI モデリング 国立陽明交通大学（台湾）、イリノイ大学アーバナ・シャンペーン校（UIUC）、サラゴサ大学、カリフォルニア大学マーセド校（UC Merced）からなる研究チームは10月20日（月）、オープンソース（Apache-2.0ライセンス）の大規模3D都市モデル生成技術「Skyfall-GS: Synthesizing Immersive 3D Urban Scenes from Satellite Ima

何を話しても理解が早かったり、勘所を抑えた意見を出してきたりする人がいる。 そういう人を目の当たりにすると、とにかくすごくて圧倒される。一体どういう頭の作りをしているのかと感じてしまうこともある。けれど当人に話を聞いてみると、それまでの "思考量" の積み重ねによって瞬発的な "思考速度" がはやいように見えるのかもしれない。このあたりの話を雑に書いてみる。 要は、そういう人は色んなことを "一度は考えたことがある" 状態なのである。 過去に経験して "2周目以降" であれば当然考えたことがあるし、直接経験していなくとも本を読んだり人と話したり、疑似体験から自分の頭の中で想定試合を繰り返している。 すごく見える人ほど、普段の思考の量が圧倒的に違う気がする。「よし考えるぞ」と集中する時間を取る以外にも、通勤中、散歩中、ふとした会話の中で常に何かを少し深く考えてみる癖がついているように見える。

こんにちは、しがないエンジニアの ky16 です。 最近、ハマトンの『知的生活のすすめ』を読んだのですが、そこで改めて「時間の使い方って大事だな」と思わされました。 エンジニアの毎日は、コードだけじゃなくて設計・調査・レビュー・MTG…と本当にいろいろ。だからこそ「時間をどう切り分けるか」で、生産性も気持ちの余裕も全然変わってくるんですよね。 今回はハマトンの考えをヒントに、私が普段やっている時間の使い方をまとめてみます。 時間は「質」で決まる（集中のゴールデンタイム） ハマトンは「時間は長さじゃなく質で決まる」と言っています。 私の場合、一番頭が冴えているのは朝。誰にも邪魔されないその時間に、設計や実装みたいな重めのタスクを置くようにしています。 逆に疲れた夜にやると、倍の時間がかかってしまうことも。 エンジニアは知的労働者だからこそ、 「どの時間に何をやるか」 の工夫が結果を大きく変え

AWS Toolkit for VS Codeとローカルマシン上でAWSをエミュレートするLocalStackが統合可能に。ローカルでAWS Lambdaの開発やテストが容易に Amazon Web Services（以下、AWS）は、Visual Studio Code（VS Code）の拡張機能として提供しているAWS Toolkit for VS Codeに、AWSのさまざまなサービスをローカルマシン上でエミュレートする「LocalStack」を統合する機能の追加を明らかにしました。 これによりローカルマシン上でAWSのサーバレスコンピューティング基盤であるAWS Lambdaに対応したアプリケーションの開発やテスト、デバッグなどがこれまで以上に容易になることが期待されます。 Serverless devs, your local testing workflow just got

もう随分と以前のことだが、友人の自衛官と飲んでいる時にこんな質問をしたことがある。 「今度の指揮官、本当に優秀な方だそうですね。きっと幕僚長（自衛隊制服組トップ）まで昇るんでしょうね」 すると相手は二人して、微妙な顔をする。 「確かに優秀な方なんですけど…。頭が良すぎて何言ってんのかよくわからないんですよね」 「優秀すぎて、なんというか…」 言葉を選んでいるが、好意的な意味で言っているわけではないことは明らかだ。 “優秀”“頭が良い”という言葉を、ネガティブな意味で使っている。 （将来、トップに昇るかもしれない優秀な人だと、やはり突き抜けすぎているのだろうか…） 当時はそんなふうに解釈したのだが、違った。 それからずいぶん経った後年、驚くような事件とともに、この時の違和感の本当の意味を理解することになる。 「言われた通りにやりました」 話は変わるが、自衛隊で4万人近い大組織のトップを務めた

GitHubber, OSS作家。Tech SaaSのPdM、スタートアップ取締役CTOや外資スタートアップのIC等を経験後現職。好きな言語はGoとPerlと中国語で雑なOSSを200以上量産している。3 times ISUCON winner. 著書「みんなのGo言語」共著他。Podcast https://oss4.fun