はじめに
15。
これが何の数字か、先に種明かしはしません。まずこの記事を書くまでの経緯から話させてください。
私はこのシリーズを書くとき、毎回同じ手順を踏みます。Zenn・Qiitaに置いてある過去記事のタイトルを全部読み直し、まだ書いていないテーマを探す。今回もいつも通りその作業をしていて、ふと気づいたことがありました。
気づいたこと：15本の記事は、実は1冊の本の目次だった
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』は、序章を含めて全16章で構成されています。今回、Zenn・Qiitaの既存記事タイトルと本の目次を突き合わせてみたところ、序章を除く15章すべてに、対応する無料記事がすでに存在していました。
| 章 | テーマ | 記事 |
|---|---|---|
| 1 | Harness Engineering | Harness Engineeringとは何か？AIエージェントの性能を決める「実行環境」の設計 |
| 2 | Loop Engineering | Loop Engineeringとは何か？AIエージェントを「失敗から改善するシステム」に変える方法 |
| 3 | Evaluation | AIエージェントの評価（Evaluation）設計入門 |
| 4 | Context Engineering | Context Engineeringとは何か？AIエージェントに「何を見せるか」を設計する |
| 5 | Tool Engineering | AIエージェントのTool Engineering入門 |
| 6 | Memory設計 | AIエージェントのMemory設計入門 — 何を覚え、何を忘れるか |
| 7 | Observability | AIエージェントのObservability設計 |
| 8 | Recovery Engineering | AIエージェントの失敗とRecovery Engineering |
| 9 | Human-in-the-loop | Human-in-the-loopとは何か |
| 10 | AIコーディングエージェント | AIコーディングエージェントの設計方法 |
| 11 | Agent2Agent Protocol | Agent2Agent Protocol（A2A）とは何か？AIエージェント同士がつながる標準規格 |
| 12 | 自己改善型エージェント | 自己改善型コーディングエージェントとは何か？Claude Codeの「自動モード」から考える |
| 13 | Claude Code/AI駆動開発 | Claude Code/AI駆動開発入門 — サブエージェントと並列実行で変わる開発ワークフロー |
| 14 | 実務導入 | AIエージェントの実務導入で、企業はどこでつまずくのか |
| 15 | RAG/ローカルLLM | RAGとローカルLLMとは何か？AIエージェントに「外部の知識」をどう持たせるか |
つまり、序章だけが記事化されていなかった。この記事は、その空白を埋めるために書いています。
「AI-native Software Engineering」という呼び方について
上の15本を書きながら一貫して感じてきたのは、AIエージェント開発でつまずく場所は、ほとんどの場合LLM自体の性能ではないということです。プロンプトをどう書くかより、
- どんな実行環境（Harness）に置くか
- 何を見せ、何を隠すか（Context）
- 間違えた後どう検出し、直すか（Loop / Recovery）
- 何を「合格」と判定するか（Evaluation）
- 何を覚えさせ、何を忘れさせるか（Memory）
- 実行を人間がどこで止めるか（Human-in-the-loop）
といった、LLMの「周り」の設計のほうが、実際に動くエージェントの質を左右していました。この一連の設計領域を、私はこのシリーズの中で便宜的に「AI-native Software Engineering」と呼んでいます。
これは業界で確立した用語ではありません。あくまで、15本の記事を書き終えて振り返ったときに、自分の中でいちばんしっくりきた呼び方です。呼び方そのものより、上の表に並んだ15個の設計領域が実在する、という事実のほうが重要だと思っています。
自己批判：この記事について正直に言うと
このシリーズを書きながら気づいたデータが1つあります。「〜とは何か」という概念解説型の記事は、「思い込みが数字で裏切られた」という一次体験ベースの記事に比べて、反応が伸びにくい傾向があります。この記事もまさにその「とは何か」型で、しかも中身は既存記事へのリンク集に近い構成です。
それでもこの記事を書いたのは、シリーズを最初から読む人のための入口が、今までなかったからです。単体の記事としての伸びより、他の15本への導線としての役割を優先しました。読み物として面白いかどうかより、地図として機能するかどうかを基準に書いています。
もう1つ正直に言うと、15本すべてが同じ深さで書けているわけではありません。実装まで踏み込んだ回もあれば、概念整理にとどまっている回もあります。その差は表からは分かりませんが、読んでいただければすぐに分かると思います。
今日から使えること：読む順番の目安
15本を一度に読む必要はありません。今の立場に応じて、次の3つの入口をおすすめします。
- AIエージェントという言葉自体に馴染みがない人 → まず1（Harness Engineering）と2（Loop Engineering）の2本。この2つが土台になっているので、ここが分かると残り13本の見通しが良くなります。
- 現場での導入を検討している人 → 14（実務導入）を先に読み、そこで挙げているつまずきポイントに関連する章（Human-in-the-loop、Observability など）を後から辿る方が、自分の状況に近い部分から読めます。
- すでに何かエージェントを動かしていて、精度や安定性で困っている人 → 3（Evaluation）と8（Recovery Engineering）から。多くの場合、モデルを変える前に、この2つが手薄になっていることが原因です。
どこから読んでも構いませんが、「LLMを差し替える前に、まず表のどこか1章分を疑ってみる」というのが、このシリーズ全体を通じて一番伝えたかったことです。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』では、この15個の設計領域を、序章を含めて1冊の流れとして体系立てて整理しています。