IDEからターミナルへ：インテリジェントエージェントエンジニアリングのための実践ハンドブック

2026年3月、マット・ヴァン・ホーンはXプラットフォームに「私が知っているクロード・コードのすべてのヒント」という簡潔なタイトルの長文記事を公開した。この記事は最終的に91万3000回の閲覧数を記録し、コメント欄は熱狂的な盛り上がりを見せた。

論争の発端は、特定のコマンドや設定パラメータではなく、彼の冒頭の発言「IDEは使わない」だった。彼は自身の作業プロセスを説明する中で、グラフィカルエディタを一度も開いたことがなく、開発はすべてターミナルのコマンドラインとplan.mdというファイルで行ったと述べた。これを不条理だと感じた人々は、コードの読み込み、デバッグ、リファクタリングをどのように行っているのかと質問したが、あるベテランエンジニアは「まさに私が探していた方法だ」とコメントした。

2か月後、中国の開発者である孟少氏は、この方法論と関連するコミュニティの実践例をまとめ、「インテリジェントエージェントエンジニアリングのための実践的ヒント完全ガイド」というタイトルで公開しました。これはツールの評価ではなく、「研究→計画→作業」サイクルを中心とした一連の運用原則であり、再現可能または議論可能な22の具体的なテクニックによって支えられています。

この記事では、オンラインで最も議論されているAIワークフロー運用ガイドをいくつかまとめており、そこからいくつかの共通点を見出すことができるかもしれない。

IDEを閉じると、何が失われますか？

グラフィカルIDEは、開発者に単なるコード編集領域以上のものを提供します。構文ハイライト機能により変数とキーワードを瞬時に区別でき、リアルタイムのエラーメッセージで入力中に問題箇所を知らせ、ブレークポイントデバッグ機能で変数の状態変化を行ごとに確認でき、ファイルツリーとパンくずリストナビゲーションで大規模プロジェクトでも迷うことなくナビゲートできるなど、完全な視覚フィードバックシステムを提供します。こうした視覚的なフィードバックメカニズム全体を通して、コーダーはコードのすべての行の状態を把握する必要があるという前提が確立されます。

ターミナルのコマンドラインとMarkdownファイルを使ったワークフローでは、この視覚的な保護シェルが取り除かれます。残るのは点滅するカーソルと手書きの設計図だけです。エラーを示す赤い波線も、自動補完のポップアップも、ファイルツリーもありません。マット・ヴァン・ホーンはツイートで「IDEなし」というフレーズを使いましたが、その真の意味はグラフィカルツールをすべて拒否することではなく、開発管理ロジックを「一行ずつ手動で確認する」方式から「一括実行」方式へと変革することです。

Claude Codeのリード開発者であるBoris Cherny氏は、2025年後半から2026年初頭にかけて、Threadsなどのチャネルを通じてClaude Codeを使用する際のアプローチについて発表しました。彼のアプローチはCLIを優先し、すべてのタスクの開始点としてプランモードを使用するものです。これはIDEの考え方とは根本的に異なります。従来のIDEでは、人間が能動的なコード作成者であり、AIによる補完は単なる補助ツールに過ぎません。一方、プラン駆動型のターミナルワークフローでは、人間が方向性を設定し、それを受け入れる側であり、コードの生成と実装のパスはエージェントによって自律的に選択されます。

IDEを手放すということは、「コードを一行ずつ手入力する」という安心感を失うことを意味します。これは損失のように聞こえるかもしれませんが、大規模プロジェクトで数多くのコンテキストスイッチを経験してきた開発者にとっては、一種のオフロードでもあります。なぜなら、コードの閲覧、コードの記述、ドキュメントの検索、ファイルの切り替えといった作業を何度も繰り返す必要がなくなるからです。必要なのは、要件を明確に定義し、実行プロセスを並列で動作するエージェント群に委任することだけです。

孟少氏のフレームワークを要約すると、「人間主導の指示、インテリジェントエージェントによる実行」というものです。IDE時代においては、人間が指示と実行の詳細の両方を担当していたため、両者の役割が複雑に絡み合っていました。新しいワークフローでは、これら二つの役割を分離し、人間は指示と実行の詳細のみを担当するようにします。

plan.mdは文書ではなく、契約書です。

このワークフローで最も一般的なファイル名はplan.mdです。プロジェクト文書のように聞こえますが、実際の機能は全く異なります。

プロジェクトのREADMEや開発ドキュメントは人間が読むためのもので、アーキテクチャ上の決定事項の説明、インターフェースの慣例の記録、新規メンバーの作業開始支援などに使用されます。plan.mdの主な読者は人間ではなくエージェントです。その構造は、問題定義、解決策の説明、チェックボックス形式の実行リストという3つの要素を中心に構成されています。Meng Shaoはこの関係性をツイートで非常に明確に説明しています。plan.mdの役割は「エージェントが怠惰にならないように制約すること」です。

LLM（言語レベルモデル）には、長時間の会話において「コンテキストの破損」と呼ばれる既知の問題があります。会話履歴が長くなるにつれて、モデルが以前の目標に注意を払う能力は自然と低下します。そのため、途中で当初の要件の境界を忘れてしまったり、特定のチェック手順をスキップしたりする可能性があります。コミュニティの「Cleanliness.skill」というプロジェクトは、この問題に特化して取り組み、セッションファイルを自動的にクリーンアップし、永続メモリを更新する方法を提供しています。このプロジェクトの核心的な前提は、エージェントの長期的なパフォーマンスは、単一のプロンプトの質ではなく、安定した外部メモリ機構が存在するかどうかに依存するという点です。

`plan.md`ファイルは、この外部メモリです。ファイルシステムに保存され、セッションが終了しても消滅しません。新しいエージェントセッションでは、前回の会話の劣化したチャット履歴に頼るのではなく、このファイルからコンテキストを再読み込みできます。

Every Inc.のKieran Klaassen氏が開発したCompound Engineeringは、このワークフローを支えるコアとなるオープンソースプラグインです。このプラグインは一連のコマンドライン命令を提供し、 /ce:plan開発者の入力に基づいてドラフト版の`plan.md`ファイルを自動的に生成します。生成後、開発者はそれをレビューして修正する必要があります。エージェントは技術選択について誤った前提を持っていたり、モジュールの複雑さを過小評価していたり、ビジネスロジックを完全に誤解している可能性があるからです。この段階での人間の介入は、コードの微調整ではなく、エージェントが知らないドメイン知識を計画ファイルに注入し、修正された計画をエージェントに渡して実行させることを目的としています。

この設計は、ボリス・チェルニーがクロード・コードの原則で強調した重要な原則、すなわち、人間の専門家の判断を計画とレビューの段階に集中させ、実行のあらゆる段階に分散させないという原則と密接に合致している。チェルニーの言葉を借りれば、あらゆる段階で人間の監視と確認が必要になるのであれば、それは本質的に手作業でコードを書くことと何ら変わりない。

効果的なplan.mdファイルはそれほど長くありません。通常、明確な受け入れ基準が含まれており、それぞれがチェックボックスに対応しています。これらのチェックボックスは、エージェントの実行基準とユーザーの受け入れ基準として機能します。開発者は作業フェーズが完了した後、コードを読むのではなく、これらのチェックボックスが一つずつチェックされているかどうかを確認します。

要件の3つの形態：調査 → 計画 → 作業

このワークフローの中核となる枠組みは、調査、計画、作業の3つのフェーズからなる閉じたループです。複雑なものではありませんが、各フェーズでは、ツールによるサポートと人的関与の両面で明確な役割分担がなされています。

リサーチフェーズの目標は、エージェントが行動を起こす前に情報面で優位に立つことです。一般的な方法としては/ce:brainstormコマンドを使用したり、特定のリサーチスキルパッケージをロードしたりすることが挙げられます。Matt Van Horn は、`last30days-skill` というスキルをオープンソース化し、2026 年 3 月末までに GitHub で 10,000 以上のスターを獲得しました。このスキルの機能は、エージェントが過去 30 日間にわたって、Reddit、X プラットフォーム、Hacker News などのコミュニティから指定されたトピックに関連するコンテンツを並行してクロールし、構造化された分析サマリーを出力することです。たとえば、新しいテクノロジースタックを含むプロジェクトを開始する場合、エージェントは、手動で 12 個のブラウザタブを開く代わりに、そのテクノロジースタックに関する最新のコミュニティレビュー、既知の落とし穴、推奨される代替案を数分以内に取得できます。

調査完了後の出力は最終的な答えではなく、情報入力です。この情報は計画段階に入り、plan.mdを作成するための材料となります。

計画フェーズでは/ce:planディレクティブを使用します。調査フェーズの結果、開発者からの初期要件、およびプロジェクトの既存のコードコンテキストに基づいて、エージェントはドラフト `plan.md` を生成します。Compound Engineering の設計理念は、時間の 80% を計画とレビューに、20% を実行に費やすことです。この比率は一見すると積極的すぎるように見えるかもしれませんが、その論理は単純明快です。明確に記述された計画、明確な境界、および具体的な受け入れ基準によって、実行フェーズでの手戻りコストを最小限に抑えることができます。

計画段階では、開発者は、エージェントが行った技術的解決策に関する誤った前提を修正し、エージェントが認識していないビジネス上の制約を追加し、タスクの細分化と実行順序を調整し、エージェントがチェックボックスで簡単に見落としてしまう可能性のあるエッジケースを追加する必要があります。このレビュープロセス自体も「外部メモリ注入」の一形態と言えます。なぜなら、この段階では、会話の中で自然には浮かび上がりにくい暗黙の知識を計画文書に書き込むからです。

作業フェーズで/ce:workコマンドを使用します。エージェントは `plan.md` を読み込み、タスクをサブタスクに分割し、それらをサブエージェントにディスパッチして並列実行します。ボリス・チェルニーはかつて、このプラン駆動型ワークフローを使用して、1か月で259件のプルリクエストを作成したという統計を共有しました。この数字はコードの品質を示すものではなく、実行フェーズでの意思決定権限がエージェントに委譲されると、人間のボトルネックがタイピング速度ではなくなることを示しています。

3つのフェーズの間には、見落とされがちな重要なポイントがあります。それは、調査フェーズと計画フェーズを複数回繰り返すことができる点です。エージェントが計画フェーズ中に情報ギャップを発見した場合、いつでも調査モードに戻ってギャップを埋めることができます。同様に、作業フェーズ開始後に計画にエラーが見つかった場合も、計画フェーズに戻って修正できます。このサイクルは直線的なウォーターフォール型の流れではなく、ロールバックや調整が可能なループ構造になっています。

すぐに試せる6つのヒント。

現在入手可能な情報のうち、以下の6つのヒントはすべて明確な情報源と開発者が直接試行するのに十分な詳細情報を備えています。これらは抽象的な原則ではなく、「ターミナルに何を入力すべきか」「ファイルに何を書き込むべきか」「どのツールを使用すべきか」といった具体的な操作方法です。

ヒント1：アイデアが浮かんだらすぐに計画を立てましょう。まずは頭の中でシミュレーションするだけではいけません。

孟少氏は、自身の最初の投稿でこの点を非常に早い段階で指摘しました。彼の論理は、人間の脳はレビューには優れているものの、複雑な論理ツリー構造をゼロから構築することには向いていないというものです。開発者は新しい要件を受け取ると、習慣的に実装パスを頭の中でリハーサルしますが、ワーキングメモリの容量には限りがあるため、このプロセスは非常に非効率的です。正しいアプローチは、アイデアが浮かんだ直後に、たとえ粗雑でエラーを含み、大幅な修正が必要であっても、エージェントに最初のドラフトプランを生成させることです。問題のあるプランをレビューする方が、完璧なプランをゼロから作成するよりもはるかに簡単です。

ヒント2：プランを自分で読まず、担当者に数文で要約してもらいましょう。

長文の計画書を読むこと自体がコストです。ボリス・チェルニーの22のヒントの1つは、自然言語コマンドを使用してエージェントにTLDR（翻訳時間参照）を提供させるか、「eli5」を使用して計画の要点を最も分かりやすい言葉で説明させることです。レビューに5分ある場合は、最初の3分をエージェントに要約してもらい、最後の2分はリスクがあると思われる部分のみを確認するようにします。このテクニックの本質は、「読解力」も委任することにあります。人は必要な部分だけを読むのです。

ヒント3：多端子並列運転。

マット・ヴァン・ホーン氏はツイートで、4つ以上のターミナルウィンドウを同時に開き、異なるエージェントインスタンスで異なるサブタスクを処理できるようにしていると述べています。1つはフロントエンドページ、1つはバックエンドAPI、1つはテスト、そしてもう1つはドキュメントの取得を担当しています。このアプローチは、従来のシングルスレッド開発をマルチスレッドスケジューリングへと変革します。ただし、その代償として、統合された監視を提供するグラフィカルワークベンチがないため、異なるターミナルの出力とステータスを自分で管理する必要があります。単一のIDEウィンドウで包括的なビューに慣れている開発者にとっては、最初は「どこで問題が発生したのか分からない」という不安が生じるでしょう。

ヒント4：複雑な建築コマンドには、キーボード入力ではなく音声入力を使用してください。

孟少氏は、入力にMonologueのような音声ツールを使用することについて言及した。具体的な方法は、長文のシステム設計コンセプトをタイピングする代わりに音声で表現し、音声認識ツールでその内容をターミナルやプロジェクトファイルに取り込むというものだ。マット・ヴァン・ホーン氏はこれを「音声で集中する」と呼び、音声の方がタイピングよりも複雑なアーキテクチャ思考の一貫性を保つのに優れていると考えている。なぜなら、話す速度が論理の自然な流れに効果的に合致するからだ。しかし、この手法が中国の開発者にとって実際にどれほど効果的かというフィードバックは現状では不足しており、Monologueの中国語音声サポート機能についてもさらなる検証が必要である。

ヒント5：メールを介して非同期タスクをトリガーする。

2026年4月のツイートで、マット・ヴァン・ホーンは具体的なシナリオを紹介しました。子供を寝かしつけている間に、agentmailツールを使ってClaude Codeインスタンスにメールを送信し、リモートコードビルドタスクをトリガーしたのです。子供が眠りにつくとビルドは完了し、ターミナルには結果が表示され、承認を待つばかりでした。つまり、これは開発者を「コンピューターの前に座らなければならない」という物理的な制約から解放し、エージェントがバックグラウンドで継続的に動作することを可能にするのです。前提条件は、エージェントに対する十分な信頼があり、画面を見なくてもエージェントが自律的に実行することを許容できるかどうかです。

ヒント6：ツール群をスキルマーケットプレイスのように扱いましょう。

AgentSkillsのようなプロジェクトは、開発者がエージェントのすべての機能をゼロから構築する必要がないというコアコンセプトを提供しています。ファイル管理、ニュース監視、Webスクレイピングといった一般的な機能については、コミュニティがメンテナンスしているスキルパッケージが既に用意されており、ロードすることができます。ターミナルワークフローでは、新しいスキルをロードすることは、プラグインをインストールするのとほぼ同等です。設定でスキルパッケージのソースとパラメータを宣言するだけで、エージェントは対応するツールの機能を自動的に取得できます。コミュニティの実践例として、Claude Code Video Toolkitは、CLI環境にビデオコンテンツ理解機能を追加します。そのアプリケーションシナリオはまだ比較的限定的ですが、ターミナルエージェントの機能はスキルパッケージを通じて継続的に拡張できることを示しています。

このプロセスがあなたにとって裏目に出るのはいつでしょうか？

このワークフローにはかなりの反対意見がある。コミュニティでの議論に基づくと、問題点は主に3つの領域に集中している。

まず最初の問題は、適用可能なユーザーグループの境界です。ボリス・チェルニーの22のヒントは、ユーザーが十分なアーキテクチャ分解能力と制約を迅速に把握する能力を持っていることを前提としています。システム設計を独立して完了できる人は、「エージェントが何をすべきか、何をすべきでないか」の境界を理解しています。コードロジックを理解するためにIDEのエラーメッセージ、コードのハイライト表示、ブレークポイントデバッグに頼っている開発者にとって、グラフィカルエディタをオフにすることは、慣れ親しんだ情報取得チャネルを遮断することに等しいのです。これは能力の問題ではなく、作業方法において依存している知覚チャネルの違いです。初心者開発者は、行ごとのデバッグを通じてプログラムの実行プロセスのメンタルモデルを構築しますが、この学習プロセスにはターミナルワークフローでは代替手段がありません。

2つ目の問題は、リスクの集中です。従来のIDEでは、コンパイルエラー、型不一致、実行時例外など、エラーは実行中に徐々に明らかになります。人間は各段階で問題を発見し、修正する機会があります。一方、計画主導型のワークフローでは、すべての意思決定レビューが計画段階の単一のノードに集約されます。このノードでの人間のレビューが不十分な場合、エラーは作業段階でエージェントによって忠実に効率的に増幅されます。エラーを発見する頃には、すでに複数のファイルが誤ったロジックで汚染されている可能性があります。

マット・ヴァン・ホーン自身が「AI精神病」と呼んだ3つ目の問題は、AI自体に欠陥があるということではなく、人間のミスに起因するものです。エージェントループを構築する行為そのものが、戦略ゲームにおける継続的な最適化の正のフィードバックループと同様に、強烈な知的快感を生み出す可能性があります。開発者は、エージェントのワークフロー自体を洗練させることに没頭し、常に新しい手法を試したり、新しいサブエージェントを追加したり、プランの構造を最適化したりしますが、根本的な問いを忘れてしまうことがあります。つまり、ユーザーに実際にどのような価値を提供しているのか、ということです。ツール自体が目的となり、ユーザーのニーズは二の次になってしまうのです。

これら3つの質問はすべて同じ結論を示しています。plan.md を基盤としたターミナルワークフローは、「自分が何をしたいのかを明確に理解している」ユーザー向けの効率向上ツールであり、「何をすべきかまだ模索している」ユーザー向けの学習ツールではありません。その適用範囲は、使用する技術スタックの選択ではなく、ユーザーの習熟度によって決まります。すでにシステムアーキテクチャ全体を紙に描き終えているユーザーであれば、このワークフローによって実行速度を桁違いに向上させることができます。一方、コードを書いて問題を理解しようとしている段階であれば、IDE の視覚的なフィードバックシステムは、現時点では捨てるべきではない補助ツールと言えるでしょう。

現在、このワークフローの中核となるコンポーネントは、実行環境レイヤーのClaude Code CLIまたはCodex CLI、プロセス管理レイヤーのCompound Engineeringプラグイン、そしてスキル拡張レイヤーのlast30days-skillやagentmailなどのプロジェクトです。これらはすべて急速に改良が進められており、コマンド形式、ファイル規則、プラグインシステムは変更される可能性があります。この分野に参入する開発者は、遭遇する落とし穴に対してコミュニティによる解決策がまだ存在しない可能性があることを受け入れる必要があります。なぜなら、このチェーン全体がまだ実装の初期段階にあり、「安定したツールチェーン」の基準を満たすには程遠いからです。しかし、まさに今こそ、先駆者たちが認知的な優位性を確立する絶好の機会なのです。