記事をどれだけ読んだかを示します

2026年のLLMコーディングエージェント:懐疑論者からリアリストへ

LLMは強力で速く、常に変化している。LLMコーディングエージェントの世界は、一年前とは全く別物だ。最初のころ、ChatGPTからプロジェクトにコピペするのはStack Overflowの次世代版として新鮮で、コードの質が良くないことは誰もが分かっていた。

ポッドキャストの論調はほぼ変わった。不信と軽蔑から、渋々の受容、そして熱狂的な支持へ。みんな「レビューはちゃんとしている」と言い訳をする。レビューは大事だが、常に労力に見合うとは限らない。

LLMコーディングエージェントへの評価は過大か過小のどちらかだ。私も人間だから正しい側でいたい。でも実際に使ってきた経験からすると、すべてをぶち壊さずに価値を引き出す方法は確実に存在する。**2026年のLLMは、自分がすでに書き方を知っているコードを書くのは得意。理解していないコードは役に立たない。どちらのカテゴリにいるか忘れると危険だ。**¹

これが重要なのは、ツールを深く学ぶとはどういうことかを実際に知っているから、LLMがはったりをかましているのか本当に助けているのかが分かるから。2010年代中頃、コードが必要で、少し興味があった。VBAとAutoHotkeyが得意だった。生活が楽になったから。あまりに楽になりすぎて、すべての問題がクギに見えた。データサイエンスが爆発したときにPython。インタラクティブなフロントエンドが欲しくなったときにVue。Stack Overflowからコピペ、ChatGPTからコピペ、そして「このツールが能力を増幅するのはいつで、ただ速くゴミを生成しているだけなのはいつか」を実際に理解するまでの道を歩いてきた。


ハネムーン期

ChatGPT(3または3.5)

これが登場したときのことは誰もが覚えている。助けを求めてコードと問題をコピペして、変更されたコードをコピペして戻すのは便利だった。出力がゴミでも、コードと密接に繋がっていたからそれほど悪くないと思っていた。

ウェブ検索ができるようになると、アプローチをブレインストーミングしたり、他のプロジェクトが何をしていてどう解決したかをサクッと調べるのに使いやすくなった。SQLAlchemyがXをどう処理しているか、とか。Stack Overflowからコピペしていたなら、これはその効率化版にすぎない。落ち着いた安心感のある応答に引き込まれやすい。

ChatGPT 4

この時点でGPT-4oが出て、コピペが格段に上手くなった。CopilotやコードコンプリートのことはEいていたが試したことがなかった。結局、試すことはなかった。ChatGPT 4へのコンテキストのコピペと、そこからの出力のコピペは、これ以上なく良くて簡単になった。多少の編集は必要だったが。ひどいが素晴らしい。クリップボードに何でも入れられる小さなスクリプトも作った。コピペだ。Claude Codeはここで登場したが、ChatGPTがあったので無視した。

ChatGPTはチャットが得意だったが、チャット自体が嫌いだった。知っていることのサニティチェックや比較には良い。あの古い話と同じ。専門家の分野の新聞記事を読むと、ひびや誤りが目立つ。次の、何も知らない分野の記事を読むと「へえ、面白い」と思う。半分の話か半分が間違っているだろうと仮定する。完璧ではないし、信頼すべきではなかった。友達のように扱うべきでもなかった。


クラッシュ

Codex

驚いた。一人で動く。開発者体験はこの時点でやや物足りなかったが、セッション間でコンテキストをコピペするのは得意だ。Linuxのセットアップやフォルダ操作、journalctlを読んだり accept: too many open files の原因を調べるような、難しくはないが面倒なことをコンピューター上でやってくれるのも得意だった。Googleで調べることもできるが、Codexは実行もできる。古いゲーミングデスクトップをUbuntuサーバーに変えて実験中だったので、以前はWSLとDocker Composeしか使っていなかったが、本格的なLinux作業のパーソナルアシスタントとして重宝した。

Codexは常に車輪の再発明をしたがった。何か実質的なものでうまく動かすことは決してできなかったが、小さなおもちゃとbashスクリプトは得意だった。最終的にはそこそこ良くなり、しばらく放っておけるようになった。

全ての許可を与えて、accept を押し続けるのをやめる。するとリポジトリを暴れ回る。気まぐれで削除する。

信頼するが検証する(あるいはクラッシュを見る)

LLMを信頼するとは、その後始末を引き受けることだった。小さく、集中したタスク。良いテストを書かせる。一緒にブレインストーミングする。ウェブ検索で複数のプロジェクトを比較する。他がどうしたかを見る。自分でもできるが、速くできるようになること。反論なし。

変な決断をリアルタイムで見ているのは参考になった。悪い方向に進むのを見て修正するのが最も参考になった。これも最悪で、見ていなければならないから、ほぼ目的を損なう。まだ速いが、こうしたくはない。レビューよりミスが多すぎた。

「バイブコーディング」という言葉が嫌いだ。誰かが冗談で作った言葉が、今やただのマーケティング用語になっている。サービスを売るための親しみやすい言葉。Sonnet 3系やGPT-4系では特にうまくいかないと知りながら使っている。でも使い続けるなら、少なくとも正確に使おう。バイブコーディングはプロトタイプと探索には使える。プロダクションへの技術的負債の招待だ。問題はテクニックではなく、間違ったコンテキストで使うこと。撒いた種を刈り取ることになる。


2026年:実際に機能すること

勝つパターン

プランモード。サブエージェント。CLAUDE.md。開発者体験は実際に良くなった。Codexは好きになりたかったが、ついてこれなかった。トークン数はかなり多くなっているようだし、Claudeはチャット面でもChatGPTに追いつこうとしている。ChatGPTはClaudeのチャットより遥かに先を行っていて、Anthropicはその面では追いかけているようだ。

でも気づいたことがある。勝ったツールは機能が最も多いものではなかった。ワークフローを理解したもの:計画、実行、記憶、反復。Anthropicは私を留まらせる理由を与え続けている。メモリを追加した。私の小さなスクリプトや個人的な拡張を次々と時代遅れにし続ける。エージェントチームも。みんなが独自の特製の車輪を発明してClaudeの拡張を手作りしていたら、Anthropicが自分でそれを追加した。この姿勢が他と一線を画す大きな部分だ。

基盤となるモデルとツールが非常に良くなり、監督なしで作れるおもちゃのサイズが大きくなった。今や単発のbashスクリプトではなく、シンプルなアプリやアプレットが作れる。あるいはコンポーネントを作って後でチェックするだけでいい。簡単だ。

Sonnet 4.5、Opus 4.5(現4.6)、GPT-5.n-codexはすべて、それぞれの得意領域においては圧倒的だ。良いコンテキスト、良い例、良いCLAUDE.md。成功するためのお膳立てをして、実際に出せるものを求める。ビューを作るよう言えば作る。テストを作るよう言えば作って実行する。

放っておくとダメなテストを作る。誇らしく2,000のテストが全てグリーンで、200だけスキップと宣言する。見てみると。スキップされているのは自分が書いたもの。バグで失敗した。2,000は assert True だけで何があってもパスする。大したことじゃない:CLAUDE.mdとメモリを更新するだけ。


モデルのサイズに合わせてコードする

ここが肝心だ。自分が知らないもの、悪いパターンが認識できないものをコーディングさせるのは、おもちゃでない限り間違い。モデルのサイズに合わせてコードしなければならない。Claude-sized(shaped?)な開発。

アーキテクチャ上の制約として考えよう。モデルは認知的エンベロープを持っている。一定量のコンテキストを保持し、一定の複雑さの関係を理解し、一定の深さの状態を維持できる。そのエンベロープの中にいれば強力だ。超えるとエントロピー税が発生する。出力が劣化し、幻覚が現れ、アーキテクチャ上の決定が整合性を失う。

今のところそのエンベロープは、おそらく数個のコンポーネント、小さなサービス、スタンドアロンスクリプト程度だ。フルアプリケーションではない。複数の抽象化レイヤーを持つ複雑なシステムではない。Claudeが一度に大きなコンテキストを一貫して有用に保持できるようになれば、より大きく複雑なプロジェクトを信頼してコーディングできる。これが他のすべてを決定するボトルネックだ。²

この制約に合わせて設計するようになった。クリーンなインターフェースを持つ小さなモジュール。コンポーネント間の安定したAPIコントラクト。マイルストーンごとのローカルコンテキスト。一回の実行でのクロスカッティングな変更を少なくする。Claudeは適切に境界された問題を受け取り、成果を出す。コードベース全体と曖昧な指示を与えると、自信を持って間違ったアーキテクチャが出てくる。

副作用として人間にとってもクリーンなコードベースになる。ボーナスではなく、エンベロープを尊重した直接の結果だ。authがクリーンなAPIを持つなら、Claudeはauthのinternalをその都度再導出せずに、authに依存する機能の作業を進められる。境界が曖昧なら、Claudeは状態を保持しすぎ、推測し始める。ドリフトが始まる場所だ。

失敗モードも変わった。強固な基盤を持つよく足場が組まれたプロジェクトでは、古い問題は稀になった。ライブラリの幻覚、Python 2と3の混在、完全に壊れたテストの生成。しかし新しい失敗モードはより微妙だ。アーキテクチャのドリフト。三つ前の関数でなぜそう決定したかという経緯を見失うこと。コンテキストウィンドウが完全な意図を保持できなかったため、自信を持って間違ったものを作ること。

だから作業は楽になるのではなく激化する。ビルダーではなく常なる監査人になる。ボトルネックがタイピングから識別力に移る。ゼロからコードを書くとは別の意味で認知的に疲弊する。


LLMが実際にすること

LLMは既存のスキルを増幅する。判断力を代替しない。

良いコードがどういうものか知らなければ、LLMは教えてくれない。ただ悪いコードを速く生成するだけだ。アーキテクチャ上の決定が間違っているときに認識できなければ、LLMは喜んで美しい災害を作り上げる。エージェントはスキルをスケールさせる。無知をスケールさせない。

最大のリスクは暗闇の中でコーディングすること。Pythonを長く書いていれば、穴を掘っているときが分かる。テストが実際にテストすべきことをテストしていないときが分かる。バグの原因が大体分かる。追跡は冒険ではない。エージェントだけでコーディングしてきたジュニア開発者は、二つのアプローチを評価する準備ができていない。繰り返されるコードや増殖するマジックナンバーに気づかないかもしれない。決定的なのは、LLMが間違っているときに分からず、反論できないこと。(先日Claudeを訂正したときの言葉を引用すると:「くそ、あなたが正しい。」)

LLMは探索空間を圧縮する。評価の必要性をなくすわけではない。まだセンスが必要だ。アーキテクチャ的な直感が必要だ。なぜ間違っているか即座に説明できなくても、何かがおかしいと感じる必要がある。


強度のトラップ

LLMエージェントほど速くタイピングできないのは明らかで、それだけでいくつかのことが速くなる。特に計算や数学が絡むと「作業記憶」が広く、クレイジーなやり方でものを組み合わせられる。ビジョン、創造性、規律を持ち込むだけでいい。

LLMコーディングが作業を減らすのではなく激化するという興味深い記事がある:AI Doesn’t Reduce Work—It Intensifies It。生産性と創造の陶酔感が非常に compelling なため、人々が無料で長時間働くようになったと著者は指摘する。

正直に言う。ある夜中、スマホからClaude Codeを走らせた。5時間の制限がちょうどリセットされた。週間制限が翌日リセットされる直前。まだ全部使い切っていなかった。制限を全部使い切らないなんて想像できない。そう考えると肌が粟立つ。非常に健全だ。

この記事が述べることは感じやすく、私も感じた。陶酔のハネムーン、そしてクラッシュ。特に途中で技術的負債を片付けてこなかった場合は。エージェントで技術的負債を返済できるが、どちらにせよ無駄なトークンと失われた時間だ。ワークロードに応じて精査の強度を調整しなければならない。デリケートな状況は非常に強烈なレビューが必要だ。


実際に任せられること

プロトタイプとモックアップ

プロトタイプとモックアップは全面的に任せていい。素早く作りたいだけなら、なぜダメなんだ。2026年のLLMエージェントはこれが本当に得意だ。一セッションで終わるもの。LLMは「使えない」けどブレインストーミングやアイデア出しのための超高速バージョン0.0.0.0.1モックアップに最適だ。付箋よりうまく人を驚かせる。捨てるつもりのモックアップ。

実際に動作する「使える」プロトタイプは用心する。

大規模な機械的作業

ここで最も安定した価値を得てきた。20ファイルにわたる変数のリネーム。リファクタリング後のインポート更新。一箇所で検証済みのパターンを大規模適用。エージェントはアーキテクチャを理解する必要がない。正確で疲れ知らずであればいい。安いモデル(Haiku、Sonnet)をこれに使い、Opusは思考作業に取っておく。能力による委任であり、怠惰による委任ではない。

テスト(監督付きで)

LLMはテストを速く書く。ゴミのテストも速く書く。コツはプロジェクトのドキュメントにテスト哲学を組み込んでおき、エージェントが「良い」の意味を知っているようにすること。意味のある失敗条件を要求する。assert True や存在チェックだけのものを作成時に検出する自動監査人を走らせる。エージェントが最初の草案を書き、監査人がお手軽テストを見つけ、エージェントが修正する。

フロントエンドの作業は、まだ人間の目が必要不可欠だ。Claudeはブラウザ自動化を実行でき、それは大いに助かる。それでも、ユーザーが感じる摩擦、混乱、退屈を感じることはできない。

境界された機能作業

クリーンなモジュール境界があれば、Claudeにきちんとスコープされた機能を渡して出荷可能なものを得られる。明確な受け入れ条件と従うべき既存パターンを持つ「ブログ一覧ページにタグフィルターを追加する」。それは機能する。計画なしの「認証システムを再設計する」は機能しない。

鍵は境界されたという言葉だ。Claudeは制約の中で輝く。自由を与えると全部使い切る。たいていは望まない方向に。

責任

コードをプッシュしたら、それはあなたのものだ。誰が書いたかは関係ない。LLMが書いてあなたが信頼した。ダメなら、あなたの責任だ。100%あなたのもの。


終わりに

残りの分野は動きが速い。Kiro(無料ティアからOpusを削除=泣く)³、リポジトリ分析やPRレビューの特化ツール。手作業ではとても難しいことを作っている。サイトビルダーはまだ十分なレベルでは実現できないものをマーケティングしている。小さなサイトとCRUDなら、でも本物のビジョンは任せられない。

モデルのサイズに合わせてコードせよ。信頼性を高める足場を作れ。ただ勝手にうまくいくことを願うな。モデルはどんどん良くなるが、判断力の問題は消えない。ただ移動するだけだ。

次回:Claudeの実際の使い方。ロードマップの規律、コンテキスト管理、そしてLLMエージェントとの毎日の作業のために構築したオペレーティングマニュアル。


¹ 2026年2月時点での話。クリスマスまで生き残れれば、この記事全体が無効になっているはず ² この草稿を書いた翌日にSonnet 4.6と1Mトークンコンテキストが出た ³ これらのモデルやツール名は2年後には無関係かもしれないが、今名前を挙げておく