「基盤は自社で作るべきか」に答えが出た後の方へ

エージェントの実行基盤を自社で持つべきか検討して、買う側でいこうと決めた発注側の方に向けて書いています。前提は公開8日で17万スターのハーネスが現れましたで整理しました。実装は無料で手に入る部品になり、囲い込みは別の場所へ移った、という話です。

では移った先に何を置くのか。ここに具体的な答えを出している記録が公開されました。

機構は買える側に回りました

メルカリのエンジニアリングブログが2026年6月30日に公開した実践記録があります（AI-Native な開発の実践に向けて）。エンジニア2人とプロダクト・デザイン各1人という小さなチームで、AIを前提に開発を組み直した記録です。

注目したいのは、この記事が自チームでは作らないと決めた領域です。評価ループ、hooks、権限のプロンプト、サンドボックス。エージェントを安全に動かすための機構一式を、汎用部品として外から提供される方向にあるものとして扱い、優先順位から外しています。

自社で作り込む価値が薄い、という判断です。プラットフォーム側が整えてくるものに時間を使わない。

それでも外注できないものが1つ残ります

案件ごとの判断基準です。

何が正しく何が誤りかという線引きは、その業務の価値観そのものなので、外から買えません。

判断基準は「正解」ではありません

ここを取り違えると、蓄積するものを間違えます。

残すべきなのは出来上がったコードや仕様書ではなく、そこへ至る線引きのほうです。同じ機能でもこの会社ではこう呼ぶ、この条件は合格でこの条件は差し戻す、この処理は危険側に倒す。ドメイン知識と開発ルールを併せたものが判断基準で、これは案件ごとに違います。

前記事で「実質の乗り換えコストは評価と統合の蓄積に宿る」と書きました。その蓄積の中身が、これです。

残し方は成果物の形で決まります

メルカリの記録は、判断基準を4つの形に分けて置いています。頭の中や口頭のレビューに残すのではなく、AIが次から参照できる置き場所を決めているのが要点です。

残すもの 置き場所
同じ概念に同じ名前を使う規則 ルール化して記録し、レビュー指摘を skill へ蓄積
なぜその設計にしたかの経緯 RDR・ADR として spec や design 本体とは分離
合格条件と期待される結果 テストコード
個人情報の扱い 三段階の防御とマスキングルール

分離がポイントです。判断の経緯を仕様書の中に混ぜて書くと、仕様が更新されるたびに経緯が上書きされて消えます。別の場所に置くから、後から「なぜこうなっているのか」を読み直せます。

テストから AI を抜く、が一番効きます

4つのうち、発注側がすぐ確認できるのがこれです。

メルカリの記録は、テストを推論ではなく決定論にすると書いています。AIに新しい機能の操作手順と期待される結果を書かせる。書き終わったら、その後の実行ループからはAIを抜く。以降は同じ手順を機械が同じように実行するだけになります。

なぜこうするか。AIに毎回判定させると、判定そのものが揺れるからです。同じコードでも通ったり落ちたりする検収は、検収として機能しません。一度書き出した合格条件を固定してはじめて、それが判断基準の記録になります。

AIが書いたものを人がどう受け取るかはAIが作ったコードを人がレビューする理由で書きました。レビューで出た指摘を毎回言い直しているなら、それはまだ資産になっていません。

発注側が確認すること

開発を外部へ委託するとき、成果物リストにコードとドキュメントしか並んでいないことがあります。それだと判断基準は相手側に残ります。

委託先と決める4項目

  • 命名と用語の置き場所: 自社の業務用語とコード上の名前の対応表を、どのファイルに置いて誰が更新するか
  • 判断経緯の記録形式: 設計判断の理由を、仕様書とは別の形で残すか。残すなら書式と保管場所はどこか
  • テストの帰属: 合格条件を書いたテストコードが自社に残るか。委託先の環境にしかない状態になっていないか
  • レビュー指摘の行き先: 指摘が口頭やチャットで消えず、次から参照される場所へ落ちる導線があるか

4項目とも「誰が持つか」ではなく「どこに置くか」を聞いてください。持ち主は契約で決まりますが、参照できるかは置き場所で決まります

外部と組みながら内製を止めない進め方はAI開発の伴走支援とはで整理しています。

現場メモ

私たちが受託で入るとき、最初に作るのが用語の対応表です。顧客の社内で使われている言い方と、コードやテーブルに出てくる名前が、たいてい一致していません。同じものが3通りに呼ばれていることもあります。

この対応表を自分たちの手元にだけ置くと、案件が終わったときに一緒に持ち帰ってしまいます。次に別の会社が入ったら、また同じ聞き取りから始まる。だから顧客のリポジトリに置いて、更新も顧客側でできる形にします。

正直に書くと、これは受託側にとって不利な作りです。乗り換えやすくなるので。ただ、対応表を握って離さない相手と長期の開発をしたい発注側はいません。乗り換えられる状態にしたうえで選ばれるほうが、結果として長く続いています。

買う判断と、残す判断は別です

基盤を買うと決めたことと、何も自社に残らないことは同じではありません。機構が外から手に入るようになったぶん、判断基準の記録が相対的に重くなりました。

いま外部委託の成果物リストを作っている段階でしたら、お問い合わせからご相談ください。何を納品物に加えれば判断基準が自社へ残るのか、リストの形から一緒に整理します。