AIツールを選ぶとき、発見・調整・実行・検証を分けて考える理由
AI業務を4段階に分けてツールと担当者を見直します。利用実態調査の限界、連携規格の役割、製品を切り替える際に残すべき記録を整理しました
ビジネスモデルの名前だけでは仕事のやり方を説明しにくい
AIで仕事を終えた日を振り返ってみると、複数のツールを行き来していることがあります。検索で資料を集め、要求事項を整理し、別のツールでファイルやコードを直したあと、結果を確認します。ところが「どのAIを使っていますか」という質問には、会社名ひとつで答えようとします。
私はツールを選ぶとき、この過程を発見・調整・実行・検証に分けてみると役に立つと考えています。この四つの段階は、私が業務を見渡すために設けた区分です。すべての仕事がこの順序どおりに進むとか、段階ごとに別の製品を買うべきだという意味ではありません。
どこで仕事が滞っているかがわかれば、何を変えるべきかも具体的に語ることができます。資料を探すのに時間がかかる組織と、結果を検討する基準がない組織とでは、同じツールを追加しても効果が違ってくるはずですから。
見出しは「はじめに」等の固定見出しではないため、原文の見出しをそのまま自然な日本語に整える程度で問題ありません。内容を精査した結果、以下の通り修正します。
使用研究では、人間が計画を、エージェントが実行をより多く担った
Anthropicは2026年6月の報告書で、2025年10月〜2026年4月に約23万5,000人が作成したClaude Codeセッション40万件を分析しました。対話履歴をモデルで分類した結果、計画に関する決定の約70%は人間に、実行に関する決定の約80%はClaudeに帰属していました。How Claude Code is used in practice
ここで言う計画とは、何を作り、どのような結果を完了とみなすかを決めることです。実行とは、修正するファイルやコード、使用するコマンドを選ぶことです。同じ対話の中でも、役割が分かれている様子がうかがえます。
研究が言う専門性も、肩書きではなくその課業に対する理解度を指します。指示の正確さ、確認を求める内容、エージェントの誤りを正す様子などを基準に分類しました。報告書は、経理担当者がコーディング言語を知らなくても、勘定照合のルールや例外を正確に指定できるなら、その課業の専門家でありうると説明しています。
そのように分類した初心者セッションの「検証された成功」の割合は15%、中級以上は28〜33%でした。これは、モデルが成功と判断し、なおかつテスト通過やユーザーの明示的な確認といった証拠も見つかった場合を指します。実際の企業で成果物が採用されたか、売上やコストが変わったかまで観測した成功率ではありません。
したがって、この数値をあらゆる職業のAI成果や教育の因果効果に当てはめることはできません。それでも私は、業務の基準を把握し説明できる人がエージェントを指揮するうえで有利になりうるという点に注目しました。
業務を四つの段階に分けると、抜けている役割が見つけやすい
私が使っている区分は次のとおりです。
| 段階 | 確認すべき問い | 必要な機能と役割 | 残すべき結果 |
|---|---|---|---|
| 発見 | 何を知る必要があるか | 検索、資料探索、出典確認 | 候補資料と根拠 |
| 調整 | 何をどんな順序と範囲で行うか | 計画立案、ツール連携、権限と担当者の指定 | 実行計画と許容範囲 |
| 実行 | 実際に何を変えるか | ファイル作成、コード変更、業務システム処理 | 文書・コード・チケットなどの成果物 |
| 検証 | 求めた結果は正しいか | テスト、レビュー、承認、エラー対応 | 判定根拠と修正・復旧の記録 |
発見の段階では、資料が多いというだけでは十分ではありません。自分たちの業務に関連していて、最新であり、出典を確認できる必要があります。社内資料であれば、アクセス権限や情報の欠落の有無も重要です。
調整の段階では、ツールをつなぐだけでなく責任を定める必要があります。どの情報で判断するか、誰が計画を確認するか、どの行動は実行前に承認を受けるべきか、これらを決める作業です。
実行の段階では、実際の状態が変わります。ファイルが保存されたり、チケットが修正されたり、場合によっては注文や外部への発送が発生したりします。ここでは結果を再確認し、重複実行を防ぐ設計も必要です。
検証は最後に一度だけ行う作業ではありません。資料を選ぶ際に出典を確認し、実行前に対象と範囲をレビューし、実行後に結果を検査することもできます。問題が見つかれば、前の段階に戻ることもあります。
例えば新しい商品の案内文を作るとすれば、価格と条件を調べる作業、対象顧客と表現の範囲を決める作業、草案を書く作業、事実と誤解の可能性をレビューする作業に分けることができます。一つのツールですべてを行ったとしても、これらの役割は残ります。
前述の研究が計画と実行を区別したからといって、この四段階が統計的に立証されたわけではありません。私がこの区分をする目的は、ツールが得意なことと、組織がまだ定めていないことを、あわせて確認することです。
連携規格はそれぞれ違う役割を担う
Googleの2026年3月付け開発者ガイドは、レストランの食材発注を例に、複数の規格の役割を説明しています。在庫照会、供給者とのやり取り、注文、決済承認、画面表示がそれぞれ異なる問題であることがよく示されています。Developer’s Guide to AI Agent Protocols
| 規格 | ガイドで担う役割 |
|---|---|
| MCP | ツールやデータに接続し、在庫などを照会する |
| A2A | 他のエージェントを探し、見積もり・品質・配送情報をやり取りする |
| UCP | 商品や注文・チェックアウト情報を決まった形式で交換する |
| AP2 | 誰がどのような条件で購入を許可したかを証明する記録をつなぐ |
| A2UI | エージェントが提示する画面の構成とデータを表現する |
| AG-UI | エージェントの進行状況とメッセージを画面に伝える |
これらの規格は、同じ仕事をめぐって競合する6つの製品ではありません。かといって、1回の発注で必ず6つすべてを導入しなければならないわけでもありません。現在のシステムと必要な機能に合わせて組み合わせる例です。
決済承認の記録があるからといって、実際の決済と注文がどちらも成功したとは限りません。注文完了状態と決済結果を確認し、失敗した場合にどう処理するかを決めておく必要があります。規格は情報をやり取りする約束事を提供するものであり、業務結果まで保証するものではありません。
MCPは2025年12月、Linux Foundation傘下のAgentic AI Foundationに寄贈されたプロジェクトです。公開規格を複数の主体が共同で発展させるという意味はありますが、特定の企業が使っていたツールやデータを別の製品にそのまま移せるという意味ではありません。Linux FoundationによるMCP・AAIFの説明
実務では、規格をサポートしているかどうかの先を見る必要があります。必要な機能が同じ方式で提供されているか、認証と権限が引き継がれるか、エラーや中間状態を解釈できるかを確認しなければなりません。「MCP対応」という表示ひとつだけで、連携作業が完了したと判断するのは難しいでしょう。
ツールを乗り換えるとき、何を一緒に移すべきか
より優れたモデルが登場しても、製品をすぐに入れ替えるのは難しいことがあります。対話履歴、ユーザー教育、既存業務との連携がすべてコストになり得るからです。私はその中でも特に次の4項目に注目しています。
第一に、成果物と履歴をどこに残すかです。 文書がどのドライブにあり、コードの変更がどのリポジトリに記録されているかを確認します。供給元のサーバーにあるという理由だけで、自分たちの所有物でない、あるいは書き出せないとは限りません。契約上の権利、書き出し形式、バージョン履歴の移行範囲をそれぞれ確認する必要があります。
現在のファイルしか書き出せず、修正履歴やコメントが欠落する場合もあります。逆に、組織のリポジトリに成果物を残し、複数のツールがそれを引き継いで作業できるように構成することもできます。次の作業に何の文脈が必要かをまず定めて初めて、実際の移行可能性を判断できます。
第二に、アクセス権限です。 新しいツールが同じ資料やシステムにアクセスするには、認証、組織のポリシー、セキュリティ審査を改めて合わせる必要が出てくることがあります。既存のツールを切り離したときに権限が回収されるかどうかも確認すべきです。モデルを変える作業と、システムへのアクセスを再度許可する作業は、別々に見積もる必要があります。
第三に、評価事例と判定基準です。 実際によく間違える問題、許容できる回答の範囲、合格条件を組織が保有していなければなりません。基準を製品の外に持ち出し、新しいツールでも実行あるいは検証できるかを確認するということです。記録があっても実行環境が異なれば、評価ツールを手直しするコストがかかることもあります。
第四に、接続規格と実装の違いです。 公開された規格を使えば、共通で処理できる部分が生まれます。しかし、供給元だけが提供する機能や異なるバージョンは、別途対応が必要になることがあります。規格が公開されているという事実と、乗り換えが安く済むという結論は区別すべきです。
この4項目を組織が管理していれば、乗り換えコストを抑える余地は大きくなります。とはいえ、数日で移せるというものでもありません。再検証・教育・復旧のコストは、この4項目をすべて備えていても残るのです。
一つの製品にまとめるか複数の製品を連携させるかもコストの問題です
四つの段階に分けてみると、複数の製品を使うのが正解のように感じられるかもしれません。しかし連携ポイントが増えれば、エラーが起きる箇所も、管理すべき権限も増えます。資料がどこで変更されたのか追跡しづらくなることもあります。
一つの製品の中で資料の探索から実行、レビューまでつながっているなら、文脈を受け渡すコストを減らせます。逆に、特定の段階が重要な業務では、その機能に特化した別のツールが役立つこともあるでしょう。私は、段階ごとの性能と全体の運用コストを併せて比較すべきだと考えています。
たとえば検索の品質は十分なのに実行権限がなくて仕事が止まっているなら、新しいモデルを追加しても解決しないかもしれません。逆に必要な根拠を常に見逃しているなら、実行速度よりも資料へのアクセスと検索方式を直すべきです。結果はきちんと作られているのに、採用するかどうかを誰も判断していないなら、担当者とレビュー基準こそが先に必要です。
こうした問題を切り分けるために、四つの段階に分けているのです。製品の数を増やすための分類ではなく、同じ失敗がどこで繰り返されているのかを確認するための分類です。
Oswarldの視点
ツール導入について語られるとき、モデルのスコアや応答速度に関心が集まる場面をよく目にします。私もそれ自体は重要な比較だと思っています。ただ、その話だけでは、成果物がどこに蓄積され、誰が使えると判断され、あとで別のツールに移行できるのかという問いには答えられません。
今回の使用研究で私が長く考えたのは、専門性の定義でした。肩書きとは別に、その業務の基準をどれだけ理解し、説明できるかという点です。組織に知識が蓄積されていても、担当者の頭の中にしかなければ、エージェントに十分に伝えることはできません。
だからこそ私は、基準を文章と事例として取り出す作業が重要だと考えています。何をしてはいけないのか、どんな例外があるのか、結果を何と比較すべきなのかを書き出してみることです。その文章自体が完成した評価セットというわけではありませんが、事例と判定方法を加えれば、繰り返し検討できる資料になります。
コードにしても、テストを通過しただけではすべての品質が確認されたことにはなりません。戦略や文章作成であれば、なおさら複数の判断が必要です。こうした業務でも、根拠が妥当か、要求された制約を守っているか、誰がどんな理由で結果を採用したのかを記録として残すことはできます。完璧な自動採点がなくても、検討の基準を明示することはできるのです。
前回の記事で、Googleのフォロー機能と測定情報の違いを取り上げたことがあります。連携機能が使えるということと、必要な利用記録を確保できるということは、別の問題でした。AIツールについても、どんな記録を組織が保持し、次の判断に使えるのかを確認する必要があると考えています。
私がツールを選ぶ際に重視しているのは、私たちが結果を判断し、次の選択のための材料を残せるかどうかです。どの段階で時間がかかったのか、失敗した理由は何か、修正後に結果は改善したのか。これらを記録してこそ、次の導入や再契約について具体的に議論できるからです。
💬 発見・調整・実行・検証のうち、今いちばんつまずきやすい段階はどこですか。
参考資料
- Anthropic, How Claude Code is used in practice、2026年6月16日
- Google Developers, Developer’s Guide to AI Agent Protocols、2026年3月18日
- Linux Foundation, MCPとAAIFの関係、2026年1月12日
併せて読む：検証業務と担当者設計・Googleのフォロー機能と測定情報
あなたの視点が次の号をつくります
この号で最も共感した点、あるいは違う経験をした点はどこですか。