AI駆動開発とは？自作ハーネスとネイティブ機能を7軸で比べた

伝言ゲームというのは、残酷な遊びだと思います。

小学校でやったとき、最初の文と最後の文がまったく違いました。 誰も嘘をついていません。一人ひとりが、聞こえたとおりに伝えただけです。

面白いのは、途中の誰かが「たぶんこういう意味だろう」と整理した瞬間に、大きく変わることでした。整理した人がいちばん親切だったのに、いちばん壊していました。
あのとき、7人を通って、文の長さは18字から9字に半減していました。

先に一行だけ置きます。AI駆動開発とは、AIを補助ではなく実装の主役に置いて開発を進める方法のことです。

題材は、開発サイクルを自動で回す仕組みです。工程ごとにAIの役割を分け、成果物を次の工程へ渡していきます。この土台のことを、ここではハーネスと呼びます。

前置きはさておき、本題に入ります。

今日は、このハーネスを自社で作るか、提供元のネイティブ機能に乗るかを、7つの軸で比べた話をしていこうと思います。

① 教科書どおりに、自社でオーケストレーションを組む

最初は、私が組みました。工程を定義し、渡すものを決め、順番を制御する。

理由は単純です。業務に合わせて制御したかったからです。

→ 工程ごとに役割を分ける
→ 前の工程の成果を次へ渡す
→ 指摘を台帳で管理する
→ 進捗と停滞を監視する

動きました。 そして、動いただけでなく、提供元のループより良い部分がありました。

ここまでは、教科書どおりです。
規模を置いておきます。工程は4つ、役割は2つ、1サイクルの成果物は3種類。 半年で回した回数は数十回です。

要素	数
工程	4つ
役割	2つ
1サイクルの成果物	3種類

② そのとおりに運用して、7軸に分かれる

半年ほど回して、比較の軸が7つに整理されました。そして、4軸と3軸で勝ち負けが分かれました。

自作が勝った4軸はこうです。

① 原文保全の強制。 これが最大の発明でした。指摘や指示をタグで囲み、一文字も省略せずに転記させる。 そして転記されたかを機械で検査します。

② 台帳。 指摘に永続的な識別子を振り、履歴を持ち、停滞を検知します。台帳をコードが更新するので、モデルが規約を守ることに依存しません。

③ 記憶の階層化。 実装する側のツール操作のノイズが、レビューする側の文脈を汚染しません。

④ 型付きの契約と監査可能性。 何が渡されたかが記録に残ります。

そして、負けた3軸がこれです。

① スキーマの外に落ちたデータは、永久に消える。
② 非構造なコンテキストの扱いが素朴。
③ 進化コストが一桁重い。
勝ち負けの内訳は4対3です。平均すると意味を失うので、軸ごとに見ます。

勝ち負けの内訳は4件対3件でした。勝った4件はいずれも、提供元のループに存在しない仕組みです。
ところで、勝った4件のうち最初の1件について、記録には「これが最大の発明」と書かれています。ただ、発明と呼べるほどのことはしていません。「一文字も省略せず転記せよ」と書いて、転記されたかを機械で数えているだけです。とはいえ、その1件が品質のほぼ全部を決めていました。

③ そして、いちばん深い負けは①だと分かる

3つのうち、①が構造的でした。

自作の受け渡しは、決められた項目しか運べません。 設計時に「これを渡す」と決めたものだけが次へ行きます。

対して、会話をそのまま引き継ぐ方式は違います。全部の記録が生きているので、「そういえばさっき言っていたあれ」と遡って回収できます。

言い換えると、こうなります。

→ 項目で引き継ぐ — 損失あり・確実
→ 会話で引き継ぐ — ほぼ無損失・不確実

確実に一定量が失われるのと、たいてい失われないが保証がないのと、どちらを選ぶかという話でした。

②も具体的です。渡せる非構造テキストの上限が、8,000文字（約2,000トークン）、上流からの持ち込みが6,000文字、出力の控えが1,500文字。しかも切り詰めは文の途中でも容赦なく切ります。

20万トークンを扱える時代に、予算が一桁小さい設計でした。

③は運用で効きます。引き継ぐ項目を1つ増やすだけで、スキーマの変更、指示文の変更、完了処理の変更、移行作業が全部必要になります。設定ファイルに1行足すのとは違います。

証拠も残っています。 目標の抽出処理に、4段のフォールバックが生えていました。タグで取れなければ見出しから、それも駄目ならJSON、最後は正規表現。この方式が実際に何度も壊れた記録です。
負けの3軸を、数字で並べ直すとこうです。

軸	自作の値	意味
非構造テキストの上限	8,000字	約2,000トークン
上流からの持ち込み	6,000字	文の途中で切れる
出力の控え	1,500字	同上
引き継ぎ項目を1つ増やす手数	4箇所	スキーマ・指示文・完了処理・移行

④ 原因は「全部を自作の対象にしていた」こと

原因を一つに絞ると、これでした。

守るべきものと、差し替えるべきものを分けていませんでした。

原文保全と台帳は、守るべきものです。ここは提供元のループには無く、しかも品質に直結します。

一方、コンテキストの持ち回りや引き継ぎ項目の設計は、まだ探索中のものでした。探索中のものを自作の枠に固めると、変えるたびに一桁重いコストがかかります。

固めてよいのは、答えが出たものだけでした。

⑤ 直してみる — 仕事の種類で、載せる先を変える

結論は、優劣ではありませんでした。

→ 既知のワークフローを、高い信頼性で回す層 → 自作が優位
→ 引き継ぎ設計をまだ探索している段階の仕事 → ネイティブのループが勝つ

そして、時間軸の話もあります。

自作していた仕組みと同等のものが、後から提供元の標準機能として登場しました。 決定論的なスクリプトで処理を並列化し、構造化された出力を強制する仕組みです。

私の設計が、提供元の進化によって追認された格好です。

ただし、同時にこうも記録しています。半年前に作ったシステムだが、まだ部分的には提供元のループの精度を上回っている。

追いつかれるが、まだ抜かれてはいない。 その状態で、どこを守りどこを差し替えるかを決めることになりました。
線引きの結果は、守るものが2つ、差し替えるものが3つでした。守るのは原文保全と台帳、差し替えるのはコンテキストの持ち回り・引き継ぎ項目・並列の制御です。
差し替えに動かした工数は、2週間でした。守る側には手を入れていません。

差し替えに動かした工数は10日でした。守る側には1行も手を入れていません。
記録にはこう残しています。「既知のワークフローを高信頼で回す層では自作が優位」「引き継ぎ設計をまだ探索している段階の仕事ではネイティブが勝つ」。実は、この2件は同じプロジェクトの中に同居します。ただし、どちらに載せるかは工程ごとに決められます。工程は4件、自作へ載せたのは2件でした。

⑥ あとで知った — 伝言ゲームには、定理があった

素朴な観察のつもりでしたが、多段で情報が減ることには、情報理論の定理がありました。

データ処理不等式（Data Processing Inequality）です。

内容はこうです。3つの確率変数がマルコフ連鎖をなすとき、途中の変数をどう処理しても、元の変数についてその中に含まれる情報を増やすことはできない。

もっと短い言い方も添えられています。「後処理は情報を増やせない。」

多段のAIパイプラインは、まさにこの連鎖です。

→ 指摘が出る（元の情報）
→ 次の工程が要約して受け取る（処理）
→ その次がさらに要約する（処理）

どれだけ賢いモデルを後段に置いても、前段で落ちた情報は戻りません。 賢さは処理の質を上げますが、不等式の向きは変えられない。

小学校の伝言ゲームで、整理した人がいちばん壊していた理由もこれでした。整理は処理です。処理は情報を増やしません。

だから、原文保全が最大の発明だったのだと思います。あれは工夫ではなく、唯一の逃げ道でした。減らさずに渡すこと以外に、情報を保つ方法がない。
実際、要約を挟んだ工程と挟まない工程で、指摘の取りこぼしが8件と0件に分かれました。同じ入力、同じモデルです。

新しい理屈は、ひとつも要りませんでした。

記録に残っている実例

自作側が何で勝っているかは、決定記録を見ると具体的です。

2026年2月2日の決定。 各役の出力を別々に保存し、状態と時刻を持たせています。再試行のときは、完了済みの出力をそのまま残す。 目的は3件と書かれています。失敗した場所を特定すること、利用者が各段を確認できること、そして完了した段を飛ばして再開できることです。

2026年2月3日の決定。 使うモデルの解決順は5段あります。

“`
実行時の指定 > 役 > 既定の役 > 既定の提供元 > 環境変数
“`

そして、APIキーはデータベースに置かず、環境変数の名前だけを持ちます。 鍵そのものではなく、鍵の在り処を持つ。差し替えるときに触る場所が1件で済みます。

この2件が、原文保全と台帳という表現の中身です。どちらも、あとから追えるようにするための構造であって、性能のための構造ではありません。

⑦ 何が変わったか

議論の立て方が変わりました。

“`
前：自作とネイティブ、どちらが優れているか
後：この仕事は、既知か探索中か
“`

優劣を決めようとしていたのが間違いでした。 7軸のうち4勝3敗という結果は、平均すると意味を失います。

⑧ 現場で使うなら、この2枚

表1：どちらに載せるか

仕事の性質	自作ハーネス	ネイティブのループ
手順が確定している	こちら	—
監査記録が要る	こちら	—
指摘を取りこぼせない	こちら（原文保全）	—
引き継ぐ項目がまだ決まらない	—	こちら
予期しない情報を拾いたい	—	こちら
試行の回転を上げたい	—	こちら

表2：多段パイプラインで情報を減らさない3点

点	やること	外すとどうなるか
1	原文をタグで囲んで渡す	各段で要約され、細部が溶ける
2	省略禁止を明示し、機械で検査	指示だけでは守られない
3	識別子を永続化して台帳で追う	どれが未対応か分からなくなる

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「優劣ではなく、仕事の種類で決める」。 どちらが優れているかを議論している限り、決まりません。決めるのは仕事の性質のほうです。

2件目、「スキーマの外に落ちた情報は、永久に消える」。 定義した枠に入らなかったものは、記録されません。あとから欲しくなっても取り戻せません。

3件目、「既知の工程は自作、探索中の工程はネイティブ」。 手順が確定している仕事は自作が勝ちます。引き継ぎ方をまだ探している仕事は、汎用のループが勝ちます。

4件目、「守るものと差し替えるものを、先に分ける」。 分けずに全部を自作すると、外側が良くなるたびに追随の労力が発生します。

5件目、「全部を自作すると、進化コストを自分で背負う」。 7軸で比べたとき、勝ち負けが入れ替わったのはここでした。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

提供元は、これからも機能を足してきます。自作した部分は、順に追いつかれます。

→ 自作する → 一時的に勝つ
→ 提供元が同等機能を出す → 差が消える
→ 消える → 維持コストだけが残る
半年で追いつかれた機能は2つ、まだ追いつかれていない機能は2つでした。追いつかれた側の維持に使った時間は、振り返ると無駄です。

だから、追いつかれない部分だけを自作してください。

追いつかれにくいのは、自社の業務に固有な制約です。原文保全は普遍的な工夫なので、いずれ標準になります。一方、自社の工程・自社の台帳・自社の監査要件は、提供元が作る理由がありません。

そして最後に、正直に書いておきます。この7軸の比較は、私が自分の設計を評価したものです。 作った本人が採点しているので、4勝3敗という数字自体は割り引いて読んでください。

負けの3軸を構造的だと認めたのは、割り引いたあとに残ったものです。

半年で追いつかれた機能は2件、まだ追いつかれていない機能は2件です。追いつかれた側の維持に使った時間は、振り返ると無駄でした。

もう1件、記録から引いておきます。「6か月前のシステムだが、まだ部分的に精度で上回っている」。ところが、この状態は長く続きません。とはいえ、追いつかれるまでの6か月で回した数十回のサイクルは、そのまま資産になりました。

もう1件、判断の言葉を残しておきます。「スキーマ引き継ぎは損失あり・確実」「会話引き継ぎはほぼ無損失・不確実」。ただし、どちらを選ぶかは好みではなく、仕事の性質で決まります。

最後に、社内の判断を1件だけ引いておきます。新しく参画した人から、開発フローや命名規則やシークレット管理の規定を問われたときの回答です。「これも、すでに構成が異なるので、一貫したルールは適応できない気がします。適当にやってください」。

ところで、これは投げやりな返事に見えて、標準化しないという判断です。前段にはこう書かれています。「それをソロ開発に適用するには不適切な気がするので、ローカルルールを決めて運用すれば良いと思います」。

全社で1つの型に寄せるより、プロジェクトごとに決めさせるほうが速い。 自作とネイティブの線引きも、同じ考え方の上にあります。ただし、この判断には代償があります。新しく入った人が、毎回ゼロから聞くことになります。

関連して、プロンプトエンジニアリングを属人化させない話と、アジャイル開発をAIで並行させたときの衝突話を別に書いています。ベンダーロックインで乗り換えられなくなる話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、AIプロダクト開発のページに整理しています。

---

自作といえば、本棚を作ったことがあります。既製品より高くついて、しかも傾いています。

それでも捨てられないので、いまも斜めの棚に本を置いています。 何を自作するかは、先に決めておくべきでした。

以上です。