AIエージェントの開発会社は、見積の前に何を聞いて選ぶか

AIエージェントの開発を頼む会社は、実績の件数や扱えるモデルの名前ではなく、初回の打ち合わせで5つの質問にどう答えるかで選びます。聞くのは、どの作業をエージェントに任せないか、PoCの合格を誰が何件のテストで測るか、どの操作の前に人が承認するか、渡したデータと成果物は誰のものか、本番後の保守と引き継ぎをどこまで持つか、です。見積を頼むのは、この5つに自社の業務の言葉で答えた会社だけで足ります。

AIエージェントの開発会社は、何を見れば選べるのか

AIエージェントの開発会社は、実績の数ではなく、任せない作業・PoCの合格の測り方・人が承認する場面・データと成果物の扱い・本番後の保守と引き継ぎの5つに具体的に答えられるかで選びます。初回の打ち合わせに持っていく判定表は次のとおりです。

表の言葉を先に確かめておきます。総務省と経済産業省のAI事業者ガイドライン第1.2版は、AIエージェントを、特定の目標を達成するために環境を感知し自律的に行動するAIシステムと定義しています。社内のシステムを読み、書き込み、外へ送るところまで自分で進むので、聞くことがチャットの導入より増えます。

同じガイドラインは、AIシステムの検証、ほかのシステムとの連携の実装、サービスの提供を担う事業者を「AI提供者」と呼んでいます。開発会社が請け負う仕事はおおむねここに入ります。経済産業省の「AIの利用・開発に関する契約チェックリスト」で見ると、汎用のAIサービスを開発会社が自社向けに改良・調整して提供する形は「類型2：カスタマイズ型」に近く、2段目・4段目・5段目の質問はこのチェックリストの確認項目を打ち合わせの言葉に直したものです。ガイドラインは法的な拘束力を持たない指針ですが、発注する側が何を確かめるかの物差しとして使えます。

どの作業をエージェントに任せ、どこを任せないと答えるか

任せる範囲を広く言う会社より、エージェントにしない作業を名指しできる会社を残します。打ち合わせでは、頼みたい業務を1つ説明したあとにこう聞きます。

この業務を作業に分けたとき、エージェントにしない部分はどこですか。そう考える理由も教えてください

根拠はモデル提供元の手引きです。Anthropicはエージェントの作り方をまとめた文書で、できるだけ単純な解決策から始めることを勧め、エージェント型の仕組みを作らないことが答えになる場合もあると書いています。毎回同じ順で同じ処理をする作業は、決まった手順のプログラムで足ります。エージェントが向くのは、依頼の中身によって次にやることが変わる部分だけです。

答えの見方

残すのは、業務を3つか4つの作業に切り、「ここは固定の手順、ここは人、ここだけエージェント」と分けて返す会社です。

「全部自動化できます」は外す合図です。エージェントに任せる範囲が広いほど、テストする場面も、渡す権限も、本番後に直す場所も増えます。

判断に迷うのは「業務を詳しく見ないと分けられません」という答えです。これは逃げにも誠実さにもなります。続けて「分けるために何を見せればよいですか」と聞き、帳票の実物・1日の件数・例外が起きる場面など、見たいものを具体的に挙げる会社は残してください。

PoCの合格は、誰が何件のテストで測るのか

PoCの合格条件を、契約の前に「何件のテストで、誰が採点し、何件通れば次へ進むか」まで言える会社を残し、「やってみて判断」としか言わない会社は外します。読み上げる質問はこれです。

「PoCの合格は、何件のテストで、誰が採点して、何件通れば本番の開発に進むと決めますか。テストの中身は何から作りますか」

なぜ契約の前に聞くのか

経済産業省の契約チェックリストは、開発会社に完成義務があるか、ある場合はどのような完成条件（完成時期・検収条件など）が課されるかを確かめる項目に挙げています。契約が準委任か請負かという分類よりも、成果の内容や水準をどの程度求めるかが重要な論点になる場合が少なくない、とも書いています。合格の測り方が決まっていないPoCは、終わったときに「うまくいった」と「まだ足りない」のどちらも言えてしまいます。

測り方の中身は、モデル提供元の評価の手引きが具体的です。Anthropicはエージェントの評価を、入力と成功条件を決めたテストの集まりとして組むと説明し、始めるときは実際の失敗から取った単純なタスク20〜50件で足りるとしています。これは評価を始めるときのテスト件数の目安で、合格ラインの数字ではありません。何件通れば合格とするかは公的資料のどこにも書かれておらず、業務で許される誤りの重さを見て、発注する側と開発会社が決めます。

同社の開発者向け文書は、成功の基準を数値の指標か定義のはっきりした段階評価で測れる形にすること、テストは実際の業務で来る依頼の分布を映すことも求めています。きれいな依頼だけを並べたテストで通っても、本番で来る崩れた依頼には答えられません。

答えの見方

仮の場面で比べます。初回の打ち合わせの終わりにこの質問をしたとき、一方の会社は「やってみて判断しましょう」と返し、もう一方は「実際の依頼を30件集めて、何件正しく処理できたかで決めましょう。採点は御社の担当の方にも見ていただきます」と返したとします。残すのは後者です。件数が30であることより、テストの出どころが実際の依頼で、採点に発注側が入っている点を見ます。

採点を誰が読むかも聞いてください。評価の手引きは、採点が正しく働いているかどうかは、試行の記録と採点結果を人が読まないと分からないとしています。「合格率は報告書でお出しします」だけの会社には、記録そのものを見せてもらえるかを重ねて確かめます。

エージェントに渡す権限と、人が承認する場面はどう決めるか

エージェントにどこまで権限を渡すのか。この問いに、読むだけ・書き込む・外へ送るの3つに分け、書き込みと送信の前に人の承認を置く設計として答えられる会社を残します。

「エージェントが使える操作を、読むだけ・書き込む・外へ送るに分けると、それぞれ何が入りますか。人が承認するまで止まるのはどの操作ですか」

この質問の根拠は、AI事業者ガイドライン第1.2版の別添にあります。別添は、AIエージェントが自律的に動く中で、人間の意図しない商品の注文やファイル削除などの動作を行う可能性を挙げています。外部のシステムと自律的に連携するため、挙動が不正に操作され、内部のデータが意図せず外へ送信されるおそれにも触れています。政府の資料が具体例つきで書いている以上、起きる前提で設計を聞くのが発注側の仕事です。

対応の方向も資料にあります。ガイドライン本編は、適切なタイミングで人間の判断を介在させる利用の検討を求めています。モデル提供元の手引きも、エージェントは確認点や行き詰まったところで止まり、人の指示を待つ形にできると説明しています。

答えの見方

残す答えは、操作の名前で語られます。「受注データの参照は自動、発注の登録は承認待ち、取引先へのメールは下書きまで」といった粒度です。事故が起きたときにどちらが何を負うかを契約で決めたい、と開発会社の側から言い出すなら、なお良い材料です。ガイドラインも、関係者の間の責任の所在を契約などで明確にすることを求めています。

「精度が高いので人の確認は要りません」は外します。契約チェックリストは、開発会社の保証があっても出力に不正確な情報が含まれうるとして、利用目的に応じた評価と人による確認が必要だとしています。確認を外せるかどうかは精度の話ではなく、誤ったときに何が起きる操作かで決まります。

渡したデータと出来上がった成果物は、誰のものになるのか

経済産業省の契約チェックリストは、渡した情報を開発会社が学習など提供目的以外に使えるか、開発対象と完成条件が決まっているかを、契約で確かめる点に挙げています。初回の打ち合わせでは、契約書の文言より前に、開発会社の方針を口頭で聞きます。

「開発のために渡す社内のデータは、今回の開発のほかに何かに使われますか。組み込むAIサービスの提供元の規約ではどうなっていますか」

「納品されるのは何ですか。指示文、評価用のテスト、設計書は含まれますか」

データの使い道は2段で聞く

チェックリストの該当項目は、渡した情報を、開発会社が自社の技術開発や学習などサービス提供以外の目的で使うことが許されているか、です。確かめる相手は開発会社だけではありません。チェックリストは、開発会社が第三者の汎用的なAIサービスを組み込んでいる場合も想定していて、その第三者の規約も確かめる対象になります。開発会社自身の扱いと、組み込むサービスの提供元の扱い。この2段で答えが返るかを見ます。「大手のサービスなので安全です」は答えになっていません。どの契約の形で使い、その規約のどこに書いてあるかまで言える会社を残します。

成果物は、名前を挙げて聞く

チェックリストは、開発型の契約では開発対象が不明確になる場合が少なくないと注意し、成果物の権利の帰属と利用条件は開発初期の段階で当事者の認識を擦り合わせることが重要だとしています。AIエージェントの場合、動く画面のほかに、エージェントへの指示文、合格を測ったテスト、どの操作をどこで止めるかを書いた設計書ができます。会社を替えるときや社内で直すときに要るのは、この3つです。

「ノウハウなので指示文は出せません」という答えが、直ちに悪いとは言い切れません。開発会社が複数の顧客で使う共通の部品を持っていて、それを渡せないのは筋が通ります。決めきれないときは、自社の業務に合わせて書いた部分と共通の部品を分けて、前者は渡せるかを聞いてください。そこも渡せないなら、5段目の質問の答えが重くなります。条項の書き方や権利の帰属が妥当かどうかの判断は、契約書の案が出た段階で弁護士に確かめてください。

本番に入った後の保守と引き継ぎは、どこまで含まれるのか

本番後に見るのは、変更のたびに同じテストを回す約束があるかと、成果物が手元に無い場合でも運用を続けられるかの2点です。

「モデルや指示文を変えたとき、それまでできていた処理が壊れていないかを、何で確かめますか」

「御社との契約が終わった後、自社か別の会社で運用を続けるには、何が手元に要りますか」

AI事業者ガイドラインの別添は、AIエージェントのように構成が複雑なAIシステムは、通常のAIシステムに比べてメンテナンスやトラブルシューティングの難易度が上がる場合があるとしています。動き出した後のほうが手がかかる、という前提で聞く質問です。

1つ目の質問の物差しは回帰評価です。評価の手引きは、変更を加えた後も、それまでこなせていたタスクをすべてこなせるかを確かめる評価をこう呼んでいます。PoCで作ったテストは、合格を決めたら役目が終わるわけではなく、本番後に変更のたびに回す資産になります。「不具合が出たらその都度対応します」という答えは、壊れたことに利用者が気づくまで誰も気づかない運用を意味します。

2つ目の質問は、契約チェックリストがそのまま根拠です。成果物が手元に提供されない場合に、メンテナンスや運用が十分に行えるかを事前に検討することが望ましい、とあります。残すのは、引き継ぎに要るものを自分から並べる会社です。

2〜3社の答えを横に並べる

判定表は、会社ごとに列を足して使います。5つの質問を同じ言葉で聞き、返ってきた答えをその場で短く書き込みます。打ち合わせが終わったら、段ごとに「自社の業務の言葉が入っていたか」だけを見て印を付けてください。5段すべてで具体的だった会社が1社なら、見積を頼む先は決まりです。2社残ったら2社に頼みます。

見積が出そろった後に、金額の単位をそろえて比べる段階は、AI受託開発の見積りを並べて比べるときの見方で扱っています。

公開日：2026年10月