Vibe Coding / Agentic Flow 問題集

注：本問題集には唯一の正解はありません。本文の「参考答案」は思考を喚起するためのものであり、読者自身の判断フレームをつくる手助けをするためのものです。

適用対象：毎日 Claude Code、Codex などの agentic CLI ツールを使う開発者、とくに「人とチャットする」状態から「工学的なワークフロー」に AI プログラミングを昇格させたい人。

目次

1. 背景知識編 2. 詳細整理編 3. ワークフロー編 4. システム設計編：オープンディスカッション 5. コンセプト哲学編：オープンディスカッション 6. 付録：推奨学習パス 7. 参考リンク

一、背景知識編

Q1. /command とは何ですか？ skill とどう違いますか？いつ command を使い、いつ skill を使うべきですか？

参考解答

/command、つまり Slash Command は Claude Code の初期拡張メカニズムです。ユーザーは .claude/commands/ 配下に .md ファイルを置き、会話内で /command-name と入力して起動します。本質的には「ユーザーが明示的に呼び出すプロンプト断片」です。

Skill は新世代の拡張メカニズムで、通常 .claude/skills/<name>/SKILL.md、~/.claude/skills/、または plugin に配置します。command との主な違いは次のとおりです。

実運用では、ほぼすべての新規シナリオで skill を優先すべきです。特に、モデルに適切なタイミングで手順を自動的に走らせたい場合、またはスクリプト・サンプル・テンプレートを添付する必要がある場合は、skill の方が適しています。

command は依然として、少数のシンプルなケース、例えばチームのレガシー資産として残るものや、ユーザーが明示的にトリガーすべき一行プロンプトのラッパーとして使えます。ただし新規プロジェクトで command に過度に依存することは推奨しません。

Q2. Agent とは何ですか？どのような場合に agent を使い、どのような場合に skill を使いますか？

参考解答

Agent、特に Sub-agent は、独立した system prompt、独立したコンテキストウィンドウ、独立したツールホワイトリストを持つ「小型の Claude」と考えられます。Claude Code では sub-agent は通常 .claude/agents/<name>.md で定義され、主対話がタスクを振り分けます。Sub-agent はタスク完了後、要約を主対話へ返し、途中の大量の検索・読み取り・ログ出力は主コンテキストを汚さないようにします。

Skill は一連の指示・手順です。新しいコンテキストを開かず、現在の対話内で Claude がどう動くかを誘導します。

簡単な判断基準は次です。

• Claude に「lint とテストを先に実行してから提出する」などの運用手順を伝えるだけなら skill。
• 数十ファイルを読む、grep を大量実行する、ログを分析するなど大量出力が出る場合は agent。
• 既知の単一ファイルを読むだけなら、主対話で直接読む。agent は不要。
• 推論の全過程を主対話に残したい場合、sub-agent には任せない。

Q3. Sub-agent とは何ですか？Sub-agent 同士は通信できますか？

参考解答

Sub-agent の核心は、独立コンテキスト、独立したツール群、そして主対話への summary 返信のみです。

デフォルトでは sub-agent 間で直接通信はできません。通信モデルはスター型に近く、主対話が中心ノードとして機能し、全 sub-agent は主対話とだけやり取りします。A agent の発見結果を B に渡す場合は、通常主対話が仲介します。

この設計の利点は次の通りです。

• 情報は主対話に集約されるため、監査しやすい
• agent 間の制御不能なループ会話を防げる
• コンテキストやツール呼び出しコストの暴走を抑えられる

実験的な Agent Teams では同格 agent 同士のメッセージ通信能力が導入される可能性がありますが、それはより複雑な協働モデルです。

Q4. Agent Team と Sub-agent の最大の違いは何ですか？

参考解答

Sub-agent は「短期の外注」を雇って1つのタスクをやらせ、戻ってくる報告を受けるイメージです。通常は一回きりの使い方で、主対話がタスクを渡し、sub-agent が実行し、summary を返します。

Agent Team は「継続的に協働する小規模チーム」を作るイメージです。各 teammate に独立した役割と独立コンテキストがあり、メッセージ機構で相互コミュニケーションが起こることがあります。

現実には、ほとんどの日常開発タスクは sub-agent で十分です。Agent Team は複雑プロジェクト向けのマルチエージェント研究に近く、価値は高い一方でデバッグ難易度も上がります。

Q5. MCP とは何ですか？API と何が違いますか？

参考解答

MCP（Model Context Protocol）は、外部ツール・リソース・prompt を標準形式で LLM クライアントに公開するためのプロトコルです。1 つの MCP server は、提供可能な tools、resources、prompts を宣言できます。クライアント接続時にそれらを自動検出して呼び出せます。

裸 API と MCP の違いは次です。

たとえれば、API は「店ごとに形が異なるケーブル」、MCP は「LLM 用ツール呼び出しの USB-C」のようなものです。

その価値はデータ転送だけでなく、ツールの「自己記述能力」を持たせる点にあります。モデルは、ツール名、引数、書き込み可否、確認要否を把握して、いつ・どう呼ぶべきかを推論できます。

Q6. Sub-agent は自分の sub-agent を派生できますか？

参考解答

通常はできません。Sub-agent はさらに自身の sub-agent を起動すべきではありません。

この設計は主に3つの問題を避けるためです。

1. 無限再帰：agent が無制限に派生できると、呼び出しツリーが制御不能になります。 2. 監査不能：ネストが深くなると、主対話が各層で何が起きたか追跡しにくくなります。 3. コンテキストとコストの爆発：層ごとに独立コンテキストが増えるため、費用と遅延が急増します。

どうしても「ネスト委任」が必要な場合は、次を推奨します。

• 主対話がフラットに複数の sub-agent を派発する
• sub-agent 内部で skill を使って手順を構造化する
• 非常に複雑なタスクでは Agent Team を検討し、境界と予算を明確化する

二、詳細整理編

Q7. CLAUDE.md / AGENTS.md とは何ですか？読み込み順と優先順位は？

参考解答

CLAUDE.md と AGENTS.md は、プロジェクトまたはユーザー単位の「永続的 prompt 注入」と捉えると分かりやすいです。コード規約、テストコマンド、禁止編集ファイル、コミット規約など、agent が毎回起動時に知っておくべきルールを宣言します。

よくある階層は次です。

ドキュメント紹介記事のように長文化すべきではなく、agent が従うべきハードルールとして書くべきです。例えば：

• 修正前に関連テストを先に読む
• .env と鍵ファイルを変更しない
• 完了後に必ず npm run typecheck を実行
• 不要な依存を追加しない

実務的な経験則として、1 ファイルあたり 200 行程度以内に抑えると良いです。長すぎる内容は分割して別ドキュメント化し、参照で繋げます。

Q8. Hooks とは何ですか？よく使う hook のシナリオを挙げてください。

参考解答

Hook は、Claude Code や同種の agentic ツールのライフサイクルイベントに登録する決定的なコールバックです。モデルが「覚えておくべきこと」ではなく、実行時に強制される制約です。

よくあるイベントは次です。

• ツール呼び出し前：危険コマンドのブロック
• ツール呼び出し後：ファイル編集後の自動フォーマット
• セッション開始時：現在の git 状態の注入
• 停止時：デスクトップ通知の送信

よく使うシーンは以下です。

Hook の価値は「決定性」にあります。prompt はモデルが見落とすことがありますが、hook はツール層での制約です。

Q9. Permission Mode はどの種類があり、どの場面に向く？

参考解答

Permission Mode は、agent がファイル読み書き・コマンド実行・外部ツール呼び出し時にユーザー確認を要するかを決めます。

原則として、実運用本番に近づくほど権限制御は保守的にし、一次実験や分離サンドボックスに近い状況ではより寛容にします。

Q10. /compact 時、どのコンテキストが保持され、どれが失われますか？

参考解答

/compact は対話コンテキストを圧縮するものです。優先度の高い情報は保持・再注入されますが、過去のツール呼び出しの細部は完全には残りません。

通常保持・再注入されるのは次です。

• System prompt
• プロジェクトルールファイル（例：CLAUDE.md）
• ユーザーまたはプロジェクトの memory
• 会話要約
• 一部の高優先度 skill 説明

失われやすい内容は次です。

• 履歴ツール呼び出しの完全な出力
• 永続ファイルに書かれなかった一時的な読み取り詳細
• 対話内だけの一時的な取り決め
• 一部のオンデマンドロードツールの完全スキーマ

実務上の提案は、長期制約をチャット内にだけ置かないことです。重要ルールは CLAUDE.md、AGENTS.md、memory、PROGRESS.md、またはプロジェクト文書へ落とします。

Q11. Plugin と Skill の関係は？

参考解答

Skill は能力単位で、Plugin はパッケージとして配布される拡張です。

1 つの plugin は次を含みます。

• 複数の skills
• sub-agent 定義
• hooks
• MCP server
• LSP server
• バイナリツール
• デフォルト settings

つまり skill は部品、plugin は完成済みの工具箱です。チーム内で安定した AI プログラミング手順があるなら、これを plugin 化して新規メンバーがワンクリックで導入できるようにできます。

Q12. ToolSearch / Deferred Tools とは何ですか？なぜこの設計にするのですか？

参考解答

Deferred Tools の核心は、起動時にすべてのツールスキーマをコンテキストへ全投入しないことです。まずはツール名だけをモデルに知らせ、実際に必要になったタイミングで ToolSearch などの仕組みで詳細なパラメータ構造をロードします。

この設計理由は次です。

1. トークン節約：巨大な MCP server は数十〜数百の tool を持つことがあり、全 schema はコンテキストを大量消費します。 2. 注意ノイズ低減：無関係なツールが常時 prompt に残ると判断を乱します。 3. オンデマンドロード：本当に必要なときだけ詳細説明を読む。

代償として、初回ツール利用時に1回余分な round trip が発生しますが、全体としては有利です。

三、ワークフロー編

Q13. 中程度の複雑さを持つ新機能タスクを受けたら、agentic ツールでどう分解すべきか？

参考解答

典型的な流れは次です。

1. まず plan mode に入り、読み取りのみで探索し、すぐ改修しない。 2. Explore sub-agent で関連ファイルを並列検索し、エントリ、データフロー、テスト箇所を特定。 3. 主対話または Plan sub-agent で TDD 形式の方案を作成：受け入れ基準、テストケース、最小実装、検証方針。 4. 別モデルまたは review agent でクロスモデル review を実施し、盲点を補完。 5. 重要な設計分岐はユーザーに確認し、重大変更は勝手に決めない。 6. plan mode を抜け、編集可能モードへ。 7. まずテスト追加または更新を行い、次に実装。 8. 実装後、関連テスト・typecheck・lint を実行。 9. 最後に review skill または code-review agent で自己点検。

この流れのポイントは「複数 agent を立てること自体が高度さではない」という点です。探索、設計、実装、検証、振り返りを分離することが重要です。

Q14. いつ sub-agent を起動し、いつ起動すべきでないか？

参考解答

起動すべき場合：

• 調査のために 10 つ以上のファイルを読む必要がある
• 大量の grep/find やログ分析が必要
• 独立したコード review / セキュリティ review が必要
• 複数の非依存サブタスクを並行処理する
• ツール出力が長くなり主コンテキストを汚したくない

起動すべきでない場合：

• タスクが 1〜3 回程度のツール呼び出しで済む
• 既知パスを1ファイル読むだけ
• ユーザーとの往復確認が頻繁に必要
• 推論の全プロセスを主対話に残したい

一言で言えば、sub-agent は「重い検索・重い読み取り・重いログ解析」に向き、短時間で終わる軽作業には不向きです。

Q15. 主対話のコンテキスト汚染をどう防ぐ？

参考解答

いくつか制御します。

• 大量の読み取り・調査は Explore sub-agent に任せ、要約だけを返す。
• 長いコマンド出力は head、tail、grep で絞って、数千行をそのまま対話へ流さない。
• 繰り返し作業を skill 化し、毎回長いルールを貼り付けない。
• フェーズ毎に /compact して整理。
• 重要な長期情報は CLAUDE.md、AGENTS.md、memory、PROGRESS.md に記録。
• 同じファイルを同一 agent に何度も読ませない。状態確認は diff、テスト、VCS で行う。

核心原則は「コンテキストが多いほど良い」のではなく「信号対雑音比が高いほど良い」です。

Q16. バグが起きたとき、agentic ツールでどうデバッグする？

参考解答

比較的堅実な流れは次です。

1. コードをすぐ変更せず、まず再現する。 2. 安定して失敗する最小テストまたは最小ケースを作る。 3. テスト失敗を確認し、問題理解の前提が妥当であることを検証。 4. Explore でバグ発生経路上の関連ファイルを特定。 5. 仮説を立て、1つずつ検証する。推測で手当してはならない。 6. 修正後、関連テストを実行。 7. 最後に全量または重要な検証コマンドを実行。 8. agent が連続で改善できない場合、現在のコンテキストを切り、視点を変えるか別モデルに独立診断させる。

Agent デバッグで最も怖いのは「推測しながらいじる」ことです。再現手順がないと、モデルは修正を重ねるほど混沌化しがちです。

Q17. マルチ協働リポジトリで、agentic ワークフローをチーム化するには？

参考解答

チーム化の要点は、個人のノウハウをリポジトリ資産として定着させることです。

共有層には次を含めます。

• リポジトリルートの CLAUDE.md / AGENTS.md：チームのハードルール
• .claude/skills/：共有ワークフロー
• .claude/agents/：共有 sub-agent（調査・review・debug など）
• .claude/settings.json：共有 permission、hooks、ツールホワイトリスト
• PR テンプレート：AI の関与した主要判断と検証コマンドの明示

個人層には次を含めます。

• CLAUDE.local.md：個人の好み（通常コミットしない）
• .claude/settings.local.json：個人権限上書き

さらに進めるなら、チーム共通能力を plugin 化し、統一インストール・更新・保守を実現します。

四、システム設計編：オープンディスカッション

以下の問いに標準解はありません。重み付け判断フレームとリスク意識を鍛えることが目的です。

Q18. agentic なローコード基盤を設計する場合、まず何を優先すべきか？

参考方向

まず source of truth を決める必要があります。agent が生成したコードを正とするのか、低コード DSL を正とするのか。両方向同期は一見理想的ですが、実装が複雑になりやすく、容易に工学地獄になります。

他にも次の点を考慮します。

• 可逆性とバージョン管理：agent が一度に 50 コンポーネント更新した場合、diff、revert、review が可能であること
• サンドボックスと権限分離：プラットフォーム利用者の agent が DB に直接触れず、権限ゲート経由が必須
• コンテキスト供給：業務知識はどこから入れるか。ユーザー記述ルールか、既存文書の自動抽出か
• 失敗観測性：agent が第三者 API や MCP 呼び出しで失敗した際、リプレイ可能であること
• 重要判断の確認：ユーザー思考を代替しない。高影響判断は明示的に確認
• コスト可視化：操作ごとの token、API 呼び出し、レイテンシが見えること

良い agentic ローコード基盤は「魔法のボタン」ではなく、監査可能・ロールバック可能・組み合わせ可能なエンジニアリングシステムです。

Q19. 企業内 MCP ゲートウェイを設計する場合、権限・監査・レート制御はどう扱うか？

参考方向

企業向け MCP ゲートウェイは最低限次を処理する必要があります。

• 権限：役割ごとに見えるツールを分離。読み取り専用ロールには delete_* スキーマを見せない。
• 監査：各 tool call を user、agent_id、引数、戻りサイズ、所要時間、結果ステータスまで記録。
• レート制御：同一ユーザー／同一 agent の QPS、同時数、日次呼び出し回数を制限。
• データ脱敏：agent へ返す前に PII、鍵、内部機密フィールドを処理。
• フェイルオーバー方針：下流障害時に無限待機せず structured error を返す。
• バージョン管理：tool schema の変更はバージョン付与し、旧クライアントの破壊的不整合を防止。
• テナント分離：チームやプロジェクトごとにツールとデータを分離。

MCP ゲートウェイの核心は「ツールをいかに増やすか」ではなく「安全にモデルがツールを使えるようにすること」です。

Q20. マルチエージェント協働モデルはスター型とネットワーク型、どちらを選ぶべきか？理由は？

参考方向

スター型の長所は明快さ、制御性、監査容易性です。主対話が中心で、全 sub-agent がそこへ報告します。短所は主対話がボトルネックになり、並行度が限定されることです。

ネットワーク型は実チームに近く、複数 agent が相互通信し並列性は理論上高くなります。ただし問題も明確です。

• agent 間で対話ループが起きる
• コンテキスト爆発
• 責任境界が曖昧
• デバッグ難易度の大幅上昇

現実には、多くのタスクはスター型で十分です。複雑で多役割なタスクだけ、ネットワーク型を試す価値があります。その場合はメッセージ予算、スレッド上限、会話グラフ可視化、強い監査機構が必須です。

より深い問いは、エージェントの協調オーケストレーションの ROI が「1 つの強力な単一 agent」を超えているかどうかです。モデル能力が向上するほど、ネットワーク型は限定的なシナリオでのみ安定価値を持つ可能性が高いです。

Q21. AI セキュリティ review agent を設計する場合、どの落とし穴を避けるべきか？

参考方向

セキュリティ review agent は diff だけを見ればよいわけではありません。多くの問題は呼び出しチェーンや文脈にあり、変更直前の数行には表れないことがあります。

避けるべき点は：

• テスト成功を盲信すること：未カバー領域に脆弱性が集中しやすい。
• 攻撃コマンドを自ら実行すること：review フェーズでは原則読み取りのみとし、review agent を攻撃面にしない。
• ゼロ・フォールス・ポジティブを追求しすぎること：安全 review は適度な誤検知を許容し、高危険を見逃さないことが優先。
• 分類欠如：P0 / P1 / P2 の優先度を明示し、人手を集中させる。
• 説明不全：単に「unsafe」と言うのではなく、なぜ危険か、影響範囲はどこか、どう修正するかを示す。

堅実なのは、1 つのモデルが review し、別モデルが cross-check し、最終判断は人間が行う構成です。

Q22. 長期メモリ機構を設計する場合、何を記録し、何を記録しないかはどう決める？

参考方向

記録すべき内容：

• ユーザーが繰り返し訂正したコードスタイル
• プロジェクトレベルのハード制約
• よく使うコマンド
• 忘れやすいが長期有効な工学情報（例：ポート番号、テスト入口、ドキュメント場所）

記録すべきでない内容：

• 一回限りの一時会話
• 機密情報を含む内容
• すでに時効化したバグ状態
• 長期有効性が不確かな推測

長期記憶は更新機構が必要です。書き込み時に統合し重複を避ける。定期的に期限切れ項目を整理する。ユーザーが監査・編集・削除できるようにする。プロジェクト間共有も慎重に扱い、好み情報は横断可能でも、プロジェクト知識は安易に跨らないようにします。

五、コンセプト哲学編：オープンディスカッション

Q23. なぜコンテキストはシンプルであるべき？情報で詰め込んだ prompt の方が良いのではないか？

参考方向

コンテキストの価値は長さではなく信号対雑音比です。

詰め込み型 prompt は以下の問題を招きます。

• 注意力希釈：重要ルールが雑多情報に埋もれる。
• コスト増大：毎推論でより多くの token を処理することになる。
• 遅延増加：長いコンテキストは応答速度低下を招きやすい。
• デバッグ難化：障害時、どのルールが衝突したか特定しづらい。
• 進化困難：複雑な prompt は spaghetti のように積み重なり、修正が難しくなる。

良いコンテキストは「少ない情報」ではなく、「そのタスクに本当に必要な情報だけ」を保持することです。

Q24. Agent は能動的であるべきか、受動的であるべきか？いつユーザーに聞き、いつ自分で決めるべきか？

参考方向

判断は3軸で見ると整理できます。

1. 可逆性：ローカルの可逆変更は自分で決定可能。push、delete、メール送信など不可逆操作は必ず確認。 2. 影響半径：ローカルのみなら積極的でもよいが、チーム・本番・顧客に波及するなら慎重。 3. 不確実性：モデルが確信を持てない場合は「推測で進める」のではなく質問する。

優秀な agent は「何でも聞く」でも「何も聞かない」でもなく、適切な問いを選ぶものです。分岐点では問い、細部は不要に煩わせない。

Q25. Vibe Coding は hype か、パラダイム革命か？

参考方向

hype 派はこう言います。これはより賢い自動補完に過ぎない、と。複雑プロジェクトでは agent は低レベル誤りをまだ起こし、保守コストを過小評価している。

パラダイム派はこう言います。プログラミングの最小単位は「行・関数」から「意図・制約」へ上がっている。エンジニアは打鍵者から、アーキテクト、査読者、システム設計者へ役割が変わる。

妥当な中間見解は、これは確かにパラダイムの変化だが 1:1 置換ではない、ということです。高品質なエンジニアの能力を増幅し、優れた spec と review を与えることで成果が伸びます。同時に、低品質利用者の破壊力も増す。なぜなら彼らが悪いコードをより速く生成できるからです。

核心的に問うべきこと：

• agent が書いたコードの知識はどこに蓄積されるか。リポジトリ、ドキュメント、テスト、あるいは個人の頭脳か？
• コード review の重要性は、コードを書くこと自体より増すのか？
• 初級職種とプログラミング教育はどう変わるのか？

Q26. 同じ bug を繰り返し直しても直らない場合、agent を続けて試行させるべきか、終了すべきか？

参考方向

agent が同じ誤った解法を繰り返すなら、コンテキスト汚染の可能性が高いです。トークンを消費し続けさせると、行き詰まりはさらに深まることが多いです。

より良い方法は：

• 試行上限を設ける（例：連続 3 回失敗で停止）
• 現在の修正ループを中断し、最小再現・ログ・失敗テストを整理
• 別モデルで独立診断
• 必要なら人間が主要経路を直接担当

agent が止まるのは「推論が足りない」ことより、情報欠如、曖昧なテスト、コンテキスト汚染、方針の誤りが原因であることが多いです。

Q27. なぜ agentic ワークフローでは TDD が従来より重要なのか？

参考方向

agent は自信を持って間違える傾向があります。API、フィールド、戻り値を勝手に作ってしまうこともある。テストは、エージェントが本当にタスクを達成したかを客観的に判定できる数少ない仕組みです。

agentic ワークフローで TDD が特に重要なのは：

• テストは agent との共通契約になる
• 失敗テストが明確なフィードバックループを提供
• 曖昧な要件を実行可能な仕様に変換
• 受け入れテストで「見た目は完了でも実際は未完了」を防ぐ

ただし注意点は、agent にすべてを任せないことです。主要受け入れテストとセキュリティテストは人間が書くか、別モデルが独立して review するのが安全です。

Q28. 「agent が書いたコードは可読性が悪い」対処は？これはツールの問題か、使い方の問題か？

参考方向

両方あります。

ツール側では、モデルが過度な抽象化、過剰防御、過剰コメントを生みがちです。使い方側では、制約を与えず、review も行わず、初回結果をそのまま受け入れるなら、悪いコードは蓄積します。

実践的な改善は次です。

• CLAUDE.md または AGENTS.md に可読性のハードルールを明記
• 関数長、命名規則、コメントスタイルの制約を設ける
• 「簡素化・リファクタ・冗長除去」を独立ステップとして扱う
• code-review skill で agent の自己査読を強制
• 重要モジュールは人間が diff を必ず目視

agent のコードを全く読まないなら、責任を負わないインターンに本番コードを丸投げするのと本質的に同じです。

Q29. 「agent に一晩走らせたが、何をしたか分からない」—これは agent の問題か、ユーザーの問題か？

参考方向

どちらにも責任があります。

ツール提供側は観測性を提供すべきです。ファイル diff、コマンドログ、重要な意思決定点、失敗記録、フェーズ要約などが必要です。

ユーザー側も境界設定が必要です。制約なしで夜通し走らせるのは避けます。長いタスクはフェーズ分割し、各フェーズごとに明確な目的・権限範囲・checkpoint を設けるべきです。

自律実行時間が長いほど、拘束は強めるべきです。無監督で走る長時間 agent は「sudo 権限を持つ監督不在のジュニアインターン」に近く、実運用ではリスクが高いです。

Q30. Agentic ツールはプログラマーという職業を消し去るのか？

参考方向

より現実的には、プログラマーが消えるというより「プログラマーの抽象度が上がる」可能性が高いです。

弱まるのは、明確な spec をコードへ翻訳するだけの職務です。依然として重要なのは、要件理解、システム分解、正誤判断、責任負担、長期アーキテクチャの維持です。

将来重要になる役割には次が考えられます。

• Agent アーキテクト：agent 協働図、skill ライブラリ、コンテキスト戦略を設計
• AI 査読者：agent 出力を高速に review
• コンテキストエンジニア：領域知識を agent が消化可能な構造へ整備
• エンジニアリング責任者：どのタスクを自動化し、どれを人手チェックするかを決める

歴史的類比として、コンパイラはプログラマーを消し去らず、手書きアセンブリの比率を大幅に下げただけでした。AI agent も同様に、エンジニアを排除するのではなく、より高次の抽象へ押し上げる可能性があります。

六、付録：推奨学習パス

入門段階

まず公式ドキュメントを読み、最小限の能力を一通り使えるようにします。

• プロジェクト規約ファイル：CLAUDE.md / AGENTS.md
• skill
• agent
• hooks
• /compact
• memory
• Codex / Claude Code の基本 permission mode

目的は概念を暗記することではなく、各々がどの問題を解くかを理解することです。

進階段階

自分が頻繁に行う 3 つの作業を封じ込めます。例えば：

1. commit message の生成 2. PR 要約の作成 3. コード修正後の自動テスト・typecheck 実行

この段階のポイントは、「毎回 AI に同じ説明を繰り返す」運用から、「プロセスをプロジェクト資産として定着させる」運用への移行です。

上級段階

チームまたは個人プロジェクト向けに agentic workflow を構築します。

• CLAUDE.md / AGENTS.md：長期ルール
• skills/：再利用可能な手順
• agents/：調査、review、debug など専用ロール
• hooks/：決定的な制約
• PROGRESS.md：長時間タスクの状態記録
• TASKS.md：タスク分解

専門家段階

より複雑な問題に進みます。

• PreToolUse 時の hooks 権限制御
• MCP ゲートウェイと企業権限モデル
• マルチエージェント協働のメッセージ予算と監査
• 長時間 overnight workflow の checkpoint 設計
• テスト、ドキュメント、規約ファイルを agent の信頼できるコンテキストとして統合する方法

七、参考リンク

• Claude Code Docs：llms.txt
• Claude Code Docs：Hooks Reference
• Claude Code Docs：Automate workflows with hooks
• OpenAI Codex：Get started
• OpenAI Codex GitHub Repository
• OpenAI Codex：Installation Docs
• OpenAI Cookbook：Codex Prompting Guide

より多くの Codex 実践については 『Deeply Getting the Most out of Codex』 を参照できます。Claude ツール間を素早く切り替えるには CC Switch ツール紹介 を参照してください。

よくある質問

この文章はどのレベルの開発者に向いていますか？

本文の「適用対象」を参照してください。本サイトのプログラミング記事は、入門から AI プログラミングワークフローまで各層に対応しており、記事ごとに前提知識が異なります。

この記事のツールやコマンドは OS で違いがありますか？

あります。macOS、Linux、Windows でターミナル環境、パス形式、コマンド文法が異なるため、記事で OS を明示していない場合は公式ドキュメントに従って調整してください。

どの AI ツールを使って学ぶとよいですか？

Claude Code と Codex は現在、コード説明、ロジック補完、デバッグ、スクリプト生成まで対応する能力の高いプログラミング AI ツールです。関連ツールは本サイトの CC Switch ツール記事 と Vibe Coding 面接題集 を参照してください。

プログラミングで最も重要な習慣は何ですか？

見るだけより、手を動かすことが重要です。できるだけ早く実際のプロジェクト（たとえ小さくても）を見つけて触り、問題に当たったときに理論だけで終わらず、ドキュメントとコードを参照して解決することをおすすめします。