AX推進支援会社の選び方｜生成AI・RAG・AIエージェントの実装力を比較
AX（AI Transformation、AIトランスフォーメーション。AIを前提に業務や事業のやり方を変えていくこと）を進めようとすると、自社だけでは人材や経験が足りず、外部の支援会社に相談する場面が出てきます。ところが、いざ候補を並べて比べようとすると、どの会社の提案書にも「生成AI（文章などを自動で作る人工知能）の活用」「業務変革」「伴走支援」といった似た言葉が並び、何がどう違うのかが読み取りにくいことに気づきます。さらに、生成AIは短い期間で見栄えのよい試作品を作りやすい技術です。そのため、デモを見て納得して契約したものの、本番で使う段階になって、権限の制御や評価、既存システムとの連携、運用の体制といった地味な部分で行き詰まる、という経過をたどる取り組みも少なくありません。AX推進支援会社の選定が難しいのは、提案の「見え方」と、実際に動かし続ける「実装力」とが、必ずしも一致しないためです。
本記事でいう実装力とは、特定の技術に詳しいことだけを指すのではありません。社内の文書を検索して回答を作るRAG（検索拡張生成。文書を検索し、その内容に基づいて回答を作る仕組み）を、権限や更新の運用まで含めて組めるか。AIエージェント（目的に向けて道具を使いながら作業を進めるAI）に、どこまで任せ、どこで人が承認し、どう止めるかを設計できるか。生成AIのモデルを、性能だけでなく費用やデータの扱いも含めて選び、変更にも備えられるか。そして、これらを品質の確認と運用の仕組みまで含めて、自社が引き取れる形で渡せるか。こうした一連の力の総体を、ここでは実装力と呼びます。
したがって本記事は、特定の会社を並べて順位を付ける内容ではありません。会社名を挙げたランキングは、掲載の基準や時点によって結論が変わり、読者の個別の事情も反映できないためです。代わりに、どの会社を候補にする場合にも使える比較の枠組みを示します。具体的には、支援会社の類型、自社の状況の整理、評価軸、実装力を確かめる質問、RFP（提案依頼書）の書き方、比較表とスコアカード（候補を同じ軸で採点する表）、PoC（概念実証）での見極め、見積の比べ方、契約・知的財産・データの扱い、危険信号、選定後のオンボーディング（受け入れと立ち上げ）、そして失敗パターンの順に整理します。AXのロードマップそのもの、つまりユースケースの選び方や段階の設計は別の記事で扱っているため、ここでは「その計画を誰と進めるか」という選定の問題に絞ります。なお、DX（デジタルトランスフォーメーション）推進やシステム刷新と重なる論点は、AXに特有の部分だけを取り出して触れます。
読み終えたときには、候補の会社から受け取った提案書を、同じ物差しで読み比べる手順と、面談や提案依頼書の場で何を尋ねればよいかの具体的な質問が手元に残る状態を目指しています。ただし、本記事の内容は一般的な整理であり、個々の案件の最終判断は、自社の規程、扱う情報の性質、専門家の意見を踏まえて行う必要があります。
1. AX推進支援会社には、どのような種類があり、何を基準に見分ければよいのか？
AX推進支援会社は、コンサルティング型、システム開発会社（SIer。システムの構築を請け負う事業者）型、AI専門型、内製支援型、海外拠点を活用する型といった類型で整理でき、看板の分類よりも、構想・実装・運用のどこに実績と体制があるかで見分けるのが現実的です。
支援会社の選定は、何を支援してもらうのかを言葉にしないと始まりません。AX推進は、構想の段階から本番の運用までが一続きの活動であり、その全体を一つの会社が同じ深さで担えるとは限らないためです。本章では、まず支援の範囲を整理し、次に実装力の差が見えにくい理由を確認します。そのうえで、よく見られる類型の特徴と、類型を超えて見るべき点を整理します。
1.1 AX推進で外部の支援が担いうる仕事の範囲
AX推進で外部の支援が担いうる仕事は、大きく四つに分けられます。第一に、目的の整理やユースケース（AIを使う具体的な業務の場面）の選定、効果の測り方の設計といった構想の支援です。第二に、データの整備、RAGやAIエージェントの設計と構築、既存システムとの連携といった実装の支援です。第三に、評価、品質の確認、セキュリティやガバナンスの設計といった、安全に使うための支援です。第四に、稼働後の運用、改善、そして自社の担当者が自走できるようにする内製化の支援です。
なぜこのように分けて考えるかというと、会社ごとに得意な範囲が異なり、提案書の記述の厚みもその範囲に偏る傾向があるためです。構想の記述が詳しい提案書は、実装の記述が薄いかもしれません。逆に、構築の手順が詳しい提案書は、効果の測り方や運用の記述が簡潔かもしれません。どちらが良い悪いという話ではなく、自社が足りない部分を補える会社かどうか、という見方が必要になります。
注意したいのは、四つの範囲が互いに依存している点です。構想で選んだユースケースがデータの面で実現しにくければ、実装で行き詰まります。実装で権限の設計を後回しにすれば、安全に使う仕組みの段階で作り直しになります。したがって、範囲を分けて理解しつつも、範囲の間のつなぎ目を誰が見るのかを、選定の段階で確認しておくことが大切です。
1.2 実装力の差が、提案の段階では見えにくい理由
実装力の差が見えにくい第一の理由は、生成AIの試作が容易になったことにあります。一般に、文書を取り込んで質問に答える簡単な仕組みは、限られた文書と少数の想定質問であれば、比較的短い作業でそれらしく動かせます。しかし、その状態は「典型的な質問に、手元の文書で答えられる」ことを示すにすぎません。権限に応じた回答の出し分け、文書の更新への追従、想定外の質問への対応、誤りの検知、費用の管理といった、本番で必要になる性質は、デモでは表に出にくいのです。
第二の理由は、評価の基準が確立しきっていないことです。従来のシステム開発では、仕様書に対してテストを行い、合否を判定する流れが比較的整っていました。生成AIでは、出力が毎回少しずつ異なり、正解を一つに決めにくい場面も多いため、「何をもって合格とするか」を発注側と支援会社が最初に合意しなければ、品質の話が噛み合いません。提案書に「高精度」とだけ書かれていても、何に対する精度なのかが分からなければ、比較の材料になりません。
第三の理由は、実装力が人に宿る部分が大きいことです。同じ会社の中でも、担当するチームによって経験の深さは変わります。提案の場に出てくる人と、実際に作業をする人が別である場合、提案の質から実装の質を推し量ることには限界があります。この点を補うために、後の章で述べる質問集、PoCでの見極め、体制の確認を組み合わせて、複数の角度から確かめます。
1.3 支援会社の五つの類型と、それぞれの傾向
支援会社は、一般に次の五つの類型で説明されることが多いと考えられます。ただし、実際の会社はこれらを複数まとめて提供していることも多く、以下は傾向の整理であって、個別の会社の優劣を示すものではありません。
コンサルティング型は、事業や業務の分析、構想の策定、推進体制の設計に強みを持つ傾向があります。経営層との対話や、複数部門の合意形成を支える場面で役に立ちやすい一方、実装の深さは会社によって差があるため、構築を誰が担うのかを確認する必要があります。SIer型は、要件定義から開発、運用までを一貫して担う体制や、既存の基幹システムとの連携に強みを持つ傾向があります。一方で、生成AI特有の評価や運用の知見は、会社や担当チームによって濃淡があります。
AI専門型は、機械学習や生成AIの実装に特化したチームを持ち、モデルの選定や検索の工夫、評価の手法に詳しい傾向があります。反面、業務の分析や社内の合意形成、既存システムとの統合は、自社や他の会社と分担する前提になることがあります。内製支援型は、自社の担当者を育て、仕組みを自社が運用できる状態に近づけることを重視します。研修、共同作業、レビューを通じて進めるため、成果が出るまでに自社側の稼働が必要になる点を理解しておく必要があります。海外拠点を活用する型は、海外の開発拠点を使うことで、開発の体制を柔軟に構成しやすい傾向があります。言語、時差、情報管理、橋渡しの体制を確認する必要があります。
どの類型が自社に合うかは、後述する自社の状況によって変わります。たとえば、既存の基幹システムとの連携が中心の取り組みでは、連携の経験が重要になります。社内文書の検索が中心であれば、RAGの権限と更新の運用の経験が重要になります。類型の名前を見るだけで判断せず、自社の取り組みの中心が何かを先に決めておくことが、比較の出発点になります。
1.4 類型は看板ではなく、中身で確かめる
会社が名乗る類型と、実際の体制や経験が一致しているとは限りません。AIを扱うと標榜していても、実際の担当者は別の領域の出身であったり、提案は専門チームが行い、構築は別の部署や再委託先が行ったりすることもあります。したがって、看板ではなく、担当する人の経歴、過去に扱った技術の範囲、再委託の有無といった中身を、質問と資料で確かめます。
構想から実装までの流れを一貫して示している会社の例として、たとえばSYPのDX/AXコンサルティングのページでは、進め方として、事業と業務の把握、ロードマップと要件の整理、構築と検証、運用と改善の四つの段階が示されています。同ページには、要件が固まる前に作り始めると、動いてはいても解くべき課題を外した仕組みになりうる、という趣旨の注意も述べられており、構想と実装を切り離さずに考える姿勢の一例といえます。ただし、これは一社の案内にすぎず、実際の支援の質は個別に確認する必要があります。
また、AXという言葉自体の範囲は、会社によって異なります。AXを「生成AIツールの導入」と捉える会社もあれば、「業務や事業の変革」と捉える会社もあります。このため、提案書の中でAXがどの範囲を指しているかを確認し、自社が期待する範囲と合っているかを、最初の面談で言葉にしてすり合わせることが重要です。
2. 依頼する前に、自社の状況をどう整理し、何を任せて何を内製するのか？
依頼の前に、目的、対象業務、データの状況、社内の受け皿を一枚に整理し、判断と責任は自社に残したうえで、構築や専門知識は外部と分担する線引きを決めておくと、提案を同じ条件で比べられるようになります。
支援会社を比較する前に、自社の側の整理が必要です。なぜなら、自社の状況が曖昧なままでは、各社が異なる前提で提案を書くことになり、提案の差が会社の実力の差なのか、前提の違いなのかを区別できなくなるためです。この整理は、RFPを書くときの材料にもなります。
2.1 目的、対象業務、成熟度を一枚にまとめる
整理する項目は、目的、対象業務、データの状況、社内の体制、制約条件の五つです。目的は、何を良くしたいのかを一文で書きます。「生成AIを導入する」は手段であって目的ではないため、「問い合わせ対応にかかる手間を減らす」「過去の提案資料を探す時間を減らす」のように、業務の言葉で書きます。対象業務は、誰が、どの場面で、どの情報を使い、何を出力する作業なのかを書きます。
データの状況は、必要な文書やデータがどこにあり、どの形式で、誰が管理し、どの程度最新かを書きます。社内の体制は、取り組みの責任者、業務の担当者、情報システムやセキュリティの担当者を書きます。制約条件は、扱う情報の機密性、使えるクラウドの範囲、期限、予算の枠、社内規程などです。これらを一枚にまとめると、提案依頼の際にそのまま背景の説明として使えます。成熟度については、AIの利用経験の有無、データ整備の進み具合、既存システムの状況を「進んでいる／途中／これから」のように粗く区分しておくと、どの支援が必要かを考えやすくなります。
この整理の際に陥りやすいのは、現状の問題を網羅しようとして、一枚に収まらなくなることです。完璧な整理を目指す必要はありません。分からない項目は「不明」と書き、支援会社に確認してほしい点として残します。不明な点を正直に示すこと自体が、提案の質を比べる材料になります。不明点に対して、現地調査や質問で解消する方法を示す会社と、不明点を触れずに進める会社とでは、実装の過程での誠実さが異なると考えられるためです。
2.2 任せる範囲と内製する範囲の線引き
線引きの原則は、判断と責任は自社に残し、作業と専門知識を外部と分担する、というものです。たとえば、取り組みの目的と優先順位、扱ってよい情報の範囲、合格とする品質の水準、最終的な採否の判断は、外部が代わりに決めることができず、決めた結果の責任も自社が負います。反対に、検索や生成の仕組みの設計と構築、評価の実施、運用の自動化などは、専門的な作業であり、外部と分担しやすい部分です。
デジタルガバナンスを解説した記事では、成果を上げている企業は、中核となる能力は自社で持ち、中核でない業務にはSaaS（クラウド経由で提供されるソフトウェア）や外部委託を活用し、業務の重要度や特性に応じて内製と外注を使い分けていると述べています。ただし、同記事は外部委託のサービスを案内する立場の記事でもあるため、その主張は自社の状況に合わせて吟味して読む必要があります。
線引きは固定ではなく、段階によって動かします。最初は外部の比重を大きくして立ち上げ、運用が安定するにつれて自社の比重を増やしていく設計が、現実的な選択肢の一つです。その場合、知識を自社に移す方法と、移し終えたと判断する基準を契約や計画に含めておかないと、外部への依存が固定化するおそれがあります。この点は、後の章の内製化支援と契約で改めて扱います。
2.3 社内の受け皿をそろえる：担当者、データの持ち主、権限の決定者
支援会社に任せたとしても、社内で必ず必要になる役割があります。取り組み全体の責任者、業務の内容を判断できる現場の担当者、データや文書の持ち主、情報セキュリティの確認者、そして最終的に使うかどうかを決める承認者です。これらが決まっていないと、支援会社が質問を投げても答える人がおらず、作業が止まります。
AIと人の役割分担を扱った記事は、役割分担は作業の分け方ではなく責任の分け方であり、最終的な判断者を一人に決めておく必要があると述べています。この考え方は、支援会社との関係にも当てはまります。支援会社が作るのは判断の材料や仕組みであって、その結果を業務で使う責任は発注側にあります。したがって、発注側の最終判断者を誰にするかを、依頼の前に決めておくと、後の合意形成が円滑になります。
また、現場の担当者の稼働の確保も重要です。評価用の質問の作成、回答の正誤の確認、使い勝手の意見の提出には、業務を知る人の時間が必要になります。この稼働を見込まずに計画すると、支援会社の作業が進んでも、確認の待ちで全体が遅れます。何人が、どの程度の頻度で関われるのかを、あらかじめ見積もっておきます。
2.4 自社の状況によって、評価軸の重みは変わる
整理した結果は、次章の評価軸の重み付けに直接影響します。たとえば、扱う情報の機密性が高い場合は、セキュリティと権限の評価軸の重みを上げます。既存の基幹システムとの連携が取り組みの中心であれば、既存システム連携の重みを上げます。社内にAIの担当者がほとんどいない場合は、内製化支援と教育の重みを上げます。反対に、すでに社内に強いチームがある場合は、特定の専門領域を補う力の重みを上げます。
状況と重みの対応を事前に決めておくと、提案書を受け取った後で「この会社の強みに合わせて基準を変える」という、後付けの評価を避けやすくなります。基準を先に決め、その記録を残すことは、社内で選定理由を説明する際にも役立ちます。
3. 評価軸は何を立て、どう重み付けして、戦略とユースケースの設計力を見ればよいのか？
評価軸は、戦略・ユースケース設計、データとRAGの実装、エージェントの設計と運用、評価と品質保証、セキュリティとガバナンス、既存システム連携、体制、継続運用と内製化、契約と費用の九つで整理し、必須条件と加点条件に分けて重みを付けると、比較が安定します。
比較の質は、評価軸の質でほぼ決まります。軸が少なすぎると、印象や価格に判断が引きずられます。多すぎると、重要な軸が埋もれ、評価者の負担も増えます。本章では、九つの軸を全体像として示し、軸の重み付けの考え方と、最初の軸である戦略・ユースケース設計力の見方を扱います。
3.1 九つの評価軸の全体像
九つの評価軸は、四つのまとまりに整理できます。構想のまとまりには、戦略・ユースケース設計力が含まれます。実装のまとまりには、データとRAGの実装力、エージェントの設計と運用、既存システム連携とシステム刷新への対応が含まれます。品質と統制のまとまりには、評価と品質保証、セキュリティ・権限・ガバナンスが含まれます。運営のまとまりには、体制とコミュニケーション、継続運用と内製化支援、契約と費用が含まれます。
この九つは、一般的な外部委託先の選定で使われる観点を、AXの特性に合わせて並べ直したものです。ソフトウェアベンダーの評価チェックリストを扱った記事は、機能要件、非機能要件、セキュリティ、データプライバシー、連携、サポート、価格、AI機能など、複数の観点を挙げ、評価基準を数値化して、事業上の優先度に応じて軸ごとに重み付けする考え方を示しています。同記事は、機能の有無と実用性は別であり、実際の業務の流れで確かめるべきだとも述べており、本記事の「実装力」を確かめる姿勢と重なります。
軸を使うときの原則は、一つの軸で全体を代表させないことです。たとえば、デモの見栄えが優れていても、評価や運用の軸が弱ければ、本番で行き詰まります。逆に、価格が低くても、データの扱いの軸が弱ければ、後で大きな手戻りが生じる可能性があります。複数の軸で見て、弱い軸があれば、その理由と対応策を確認する、という使い方が基本です。
3.2 必須条件と加点条件に分け、重みは自社の状況で決める
評価軸は、すべてを同列に点数化するのではなく、必須条件と加点条件に分けます。必須条件は、満たさなければ候補から外す条件です。たとえば、扱う情報を社外に出してはいけない場合の、情報の取り扱い方式への適合などです。加点条件は、満たす度合いに応じて評価を高める項目です。必須条件を点数の合計に混ぜると、他の項目の高得点で必須条件の不足が隠れてしまうため、先に別の段階で確認します。
重みは、自社の状況から決めます。前章で整理した目的や制約に照らし、どの軸を重視するかを、評価者の間で話し合って決めます。重みの合意の過程で、評価者の間の認識の違いが表れます。情報システム部門は連携とセキュリティを重く見て、事業部門は業務理解とスピードを重く見る、といった違いです。この違いを選定の前に表に出して調整しておくと、提案を受けた後の議論が感情的になりにくくなります。
重みの付け方に唯一の正解はありません。大切なのは、重みを提案を見る前に決めて記録すること、そして、重みを変える場合は理由を残すことです。提案を見た後に重みを調整する運用は、特定の会社に有利な結果を作り出しやすいためです。
3.3 戦略・ユースケース設計力：提案が業務の問いから始まっているか
最初の軸は、戦略・ユースケース設計力です。見るべきことは、提案が技術の紹介から始まっているか、業務の問いから始まっているか、という点です。優れた提案は、依頼された業務について、誰が何に困っているのか、現在の流れのどこに時間や誤りが生じているのか、AIを入れる場合にどの判断を人が残すのか、といった問いを整理してから、技術の選択に入ります。
AI活用が失敗する理由を業務理解の面から扱った記事は、AI活用の失敗の根にあるのはモデルの精度よりも業務理解の不足であることが多く、判断の条件や例外、差し戻しが明文化されていないと、価値が安定しないと述べています。この指摘に照らせば、提案書で、例外処理、データの欠損、差し戻し、承認待ちといった本番の条件にどれだけ触れているかが、業務理解の深さを測る手がかりになります。
また、ユースケースの優先順位づけの根拠も見ます。「価値が高い」とだけ書かれているのではなく、価値、実現しやすさ、リスク、データの準備度といった観点で、どのように比べたのかが説明されているかを確認します。あわせて、「やらない」という判断の提案があるかも、見逃せない点です。すべてのユースケースに前向きな提案ばかりが並ぶ場合は、実現性の吟味が浅い可能性があります。実装が難しいものを難しいと明言し、順序を変える提案ができる会社は、後の段階でも現実的な判断を期待しやすいと考えられます。
3.4 評価軸ごとに、確かめる根拠の種類を決める
軸を立てても、何を根拠に評価するのかが決まっていないと、評価者が印象で点数を付けてしまいます。根拠の種類には、提案書、書面の質問への回答、面談での説明、デモ、PoCの結果、参照先への確認があります。軸によって、適した根拠は異なります。戦略・ユースケース設計力は、提案書と面談で見えやすい一方、実装力やデータの扱いは、デモだけでは分からず、質問への回答とPoCが重要になります。
この対応を決めておくと、選定の工程の設計にも役立ちます。たとえば、PoCでしか見えない軸が多い場合は、候補を絞った後にPoCを行う工程を組みます。書面で確認できる軸は、RFPの質問に入れます。面談でしか分からない軸は、面談の質問を準備します。このように、軸と手段を結びつけることで、確認漏れを防げます。
4. 生成AIとRAGの実装力は、どのような質問で見分ければよいのか？
文書の整備と更新、権限に応じた回答、評価の方法、モデルの選定と費用の管理について、運用の具体を尋ねる質問を用意し、回答に仕組みと根拠があるかどうかで見分けるのが有効です。
生成AIやRAGの実装力は、デモや資料の見栄えよりも、運用の細部についての答え方に表れます。なぜなら、見栄えの部分は短期間で作れる一方、更新、権限、評価、費用といった部分は、本番で継続して動かした経験がなければ具体的に答えにくいからです。本章では、観点ごとに質問の例と、回答の読み方を整理します。質問の多くはRFPにも入れられますが、面談の場で追加の質問をするときにも使えます。
4.1 データと文書の扱い：何を対象にし、どう整え、誰が更新するのか
RAGの品質は、検索の工夫だけでなく、元になる文書の状態に大きく左右されます。そのため、最初の質問は「どの文書を対象にし、どれを対象外にするのか、その判断を誰が行うのか」です。対象を広げすぎると、古い文書や重複した文書が混ざり、誤りの原因の切り分けが難しくなります。対象を絞る提案は、品質を管理しようとする姿勢の表れとして読めます。
続いて、文書の整備についての質問をします。表や図を含む文書、スキャンされた文書、複数の版が存在する文書を、どのように取り込むのか。正本（正式な版）をどう決めるのか。文書を検索しやすい単位に分けるとき、どのような基準で分けるのか。これらに対して、「文書の種類ごとに試して決める」「最初に代表的な文書で検証する」といった、確かめながら進める答えが返ってくるかを見ます。「どんな文書でも取り込める」という断定的な答えは、慎重に受け止める必要があります。
更新についての質問も欠かせません。「文書が更新されたとき、どのくらいの遅れで反映されるのか」「廃止された文書は誰が、どう検索の対象から外すのか」「更新作業の責任は発注側と支援会社のどちらにあるのか」を尋ねます。更新の運用は、稼働後に最も手間がかかる部分の一つです。ここが曖昧な提案は、稼働して数か月後に、古い回答が混ざる問題として表に出る可能性があります。
4.2 RAGの権限、評価、更新を確かめる質問
RAGでは、権限、評価、更新の三つが、本番での信頼性を分けます。権限については、「利用者が見る権限のない文書の内容が、回答に混ざらないようにするには、どの段階で制御するのか」と尋ねます。画面上で表示を隠すだけでは、回答の文章に内容が含まれてしまう可能性があります。回答の素材として文書を取り出す段階、つまり検索の段階で、利用者の権限に応じて対象を絞っているかを確認します。アクセス制御の方式を比較した記事は、RBAC（ロールベースアクセス制御。役割に権限をまとめる方式）は運用が単純で監査もしやすく、ABAC（属性ベースアクセス制御。利用者や情報の属性を条件に判断する方式）は柔軟だが設計と維持が複雑であり、両者を組み合わせる運用もあると整理しています。同記事はAIには触れていませんが、権限の考え方を理解する手がかりになり、支援会社がどちらの方式を、どの理由で選ぶのかを尋ねる際の参考になります。
評価については、「検索の質と、回答の質を、別々に測っていますか」「評価のための質問集は、どのように作り、誰が正解を判定しますか」と尋ねます。回答が誤っていた場合、原因が検索で正しい文書を見つけられなかったことにあるのか、文書は見つかったが生成が誤ったのかで、直し方が異なります。両者を分けて測る支援会社は、改善の道筋を持っていると考えられます。さらに、「評価の質問集を、更新や変更のたびに再実行しますか」という質問も有効です。再実行の仕組みがなければ、一度良い結果が出ても、その後の変更で質が下がったことに気づけません。
更新については、4.1の質問に加え、「検索の仕組みの更新方法を変えるとき、稼働を止めずに切り替えられるか」「検索に使う数値化の仕組みの版が変わったとき、古い版と新しい版が混在しないようにしているか」といった技術的な質問もあります。これらは専門的ですが、答え方から経験の深さが推し量れます。細部まで説明できる会社もあれば、概念の説明にとどまる会社もあります。ここでも、大切なのは「完璧であること」ではなく、「確かめる仕組みを持っているか」を見ることです。
4.3 生成AI：モデル選定の考え方を尋ねる
生成AIのモデルをどう選ぶのかは、実装力が最も表れる質問の一つです。尋ねるべきは、「どのモデルを使うか」という結論よりも、「どのような基準で選び、変更が必要になったときにどう備えるか」という考え方です。オープンソースと商用のモデルを比較した記事は、LLM（大規模言語モデル。大量の文章から学習した言語処理のAI）の選定を、性能の優劣ではなく、誰が運用し、誰が責任を負い、誰に依存するかの違いとして捉えています。同記事は、制御性、性能、カスタマイズ、費用、データの扱い、ライセンス、特定の提供者への依存を比較点として挙げ、総所有コストで評価することや、オープンソースであっても利用条件の確認が必要なことを述べています。
この整理に沿えば、支援会社への質問は、次のような形になります。扱う情報の機密性を踏まえて、外部のサービスを使うのか、自社の環境に置くのかを、どのような理由で提案しているか。性能、応答の速さ、費用の間でどう折り合いをつけているか。モデルの提供元が仕様を変えたり、提供を終了したりしたときに、自社の仕組みを作り直さずに切り替えられる設計になっているか。モデルを変えたときに、品質が保たれているかをどう確認するか。このうち最後の質問は、評価の仕組みとつながっており、評価の質問集を持つ会社は、モデルの変更にも落ち着いて対応できると考えられます。
注意したいのは、特定のモデルの名前や、公開されている性能の順位だけを根拠にする提案です。一般に、公開された性能の比較は、特定の課題の集まりに対するものであり、自社の業務や文書に対する性能を直接示すものではありません。自社の業務に近い質問で比べた結果が示されているか、あるいは、PoCでその比較を行う提案になっているかが、判断の分かれ目になります。
4.4 コスト管理：利用量の見える化と、費用を抑える設計
生成AIの費用は、利用量に応じて増える性質があります。多くのサービスは、処理する文章の量（トークンと呼ばれる文字の単位）に応じて課金されるため、利用者が増えたり、一回あたりに渡す文書が長くなったりすると、費用が大きく変わります。このため、「一回の質問あたりの費用をどう把握し、誰が見られるようにするか」「利用量が想定を超えたときの上限や通知をどう設定するか」を尋ねます。
費用を抑える設計についても確認します。たとえば、簡単な質問には軽いモデルを、難しい質問には強いモデルを使い分けること、同じ内容の処理を繰り返さないよう結果を保存して使い回すこと、背景処理をまとめて実行すること、検索で渡す文書の量を絞ることなどが一般的な工夫として知られています。支援会社がこうした工夫を、品質との兼ね合いで説明できるかを見ます。費用を下げることだけを強調して、品質の確認が語られない提案には注意が必要です。
費用管理の観点でもう一つ重要なのは、運用費用の見通しを提案に含めているかどうかです。初期の構築費用だけが示され、稼働後の利用料、保守、評価の再実行、文書の更新作業といった継続的な費用が触れられていない場合、比較の際に総額を見誤るおそれがあります。この点は、見積の比較の章で改めて扱います。
5. AIエージェントの実装力は、ガードレール・人の承認・監視でどう見極めればよいのか？
AIエージェントでは、回答の正しさに加えて、行為の影響が問題になるため、ガードレール（想定外の動作を防ぐための制限）としての権限の範囲、人の承認の位置、記録と停止の仕組みを具体的に尋ね、自律度を段階的に広げる設計になっているかで見極めます。
AIエージェントは、文章を返すだけでなく、検索や計算、他のシステムの操作といった道具を使いながら、複数の手順を進める仕組みです。そのため、誤りが生じたときの影響が、誤った文章を読んだ人が気づくという範囲を超えて、実際に更新や送信が行われてしまうという範囲に広がります。この違いを理解して設計できるかどうかが、エージェントの実装力の中心になります。
5.1 RAGとエージェントでは、確認すべき点が増える
RAGは、基本的に文書を検索して回答を作る仕組みであり、結果は人が読んで使います。これに対しエージェントは、目的を与えられると、途中の手順を自ら計画し、必要な道具を呼び出し、結果を踏まえて次の手順を決めます。道具には、情報の検索、データベースの参照、メールの下書き、チケットの起票、場合によってはデータの更新などがあります。
確認点が増える理由は三つあります。第一に、手順が複数にわたるため、途中の誤りが後の手順に波及します。第二に、道具を使うため、操作の対象となるシステムの権限と整合させる必要があります。第三に、同じ依頼でも、実行のたびに手順が変わりうるため、結果の再現と検証が難しくなります。したがって、エージェントを提案する支援会社には、RAGで確認した項目に加え、以下で述べる、操作の範囲、承認、記録、停止についての設計を尋ねます。
5.2 ガードレールと権限：何を許し、何を許さないのか
ガードレール（想定外の動作を防ぐための制限）の設計では、まず、エージェントが使える道具と、その操作の範囲を決めます。WebアプリとAIの統合設計を扱った記事は、道具の実行には許可する操作の一覧と引数の検証を用い、出力の検査は最後の安全網として位置づけるべきだとしています。この考え方に従えば、支援会社に尋ねるべきは、「禁止する言葉を検出する仕組みがありますか」ではなく、「そもそもエージェントができる操作の範囲を、どう絞っていますか」という点になります。
たとえばSYPのAIエージェント開発のページでは、アクセス制御は画面で隠すのではなくデータの層で行い、役割、レベル、プロジェクトに応じて絞り込むこと、「AIが提案し、人が決める」という原則のもとで、結果を伴うものは人が承認すること、評価と費用の可視化を最初の試験運用の段階から行うことが示されています。これは一社の案内にすぎませんが、権限、承認、評価、費用という論点をどこまで具体的に述べているかを見る、一つの参照の枠になります。同ページは引き継ぎや知的財産の条件までは述べていないため、そうした点は別途確認が必要です。
権限については、エージェントが誰の権限で動くのかが重要です。利用者本人の権限で動くのか、エージェント専用の権限で動くのかで、情報の漏えいの危険性と、操作の記録の取り方が変わります。一般に、必要最小限の権限だけを与える考え方が基本であり、広い権限を持つ一つのアカウントでまとめて動かす設計は、慎重に見る必要があります。
5.3 人の承認：どの操作で、誰が、何を見て承認するのか
人の承認は、エージェントの安全を支える重要な仕組みですが、設計次第で形だけのものになります。尋ねるべきは、承認が必要な操作をどう決めているか、承認者に何が表示されるか、承認者が不在のときにどうするかです。たとえば、情報の参照は自動、下書きの作成は自動、外部への送信やデータの更新は承認が必要、削除や支払いに関わる操作は行わない、といった段階を設ける設計が考えられます。
承認の画面に、提案の根拠や、操作の対象と内容が分かりやすく表示されるかどうかも大切です。承認者が内容を理解できない画面では、承認が単なる通過儀礼になり、安全性が高まりません。また、承認の件数が多くなりすぎると、確認が雑になる可能性があります。そのため、承認が必要な範囲を適切に絞り、リスクの低い操作は自動化し、リスクの高い操作に人の注意を集中させる設計が望まれます。
AIと人の役割分担を扱った記事は、承認の段階が安全のために増えると、判断が遅くなり、特定の人が不在のときに止まるという別の問題が生じること、判断の基準を短く整理し、リスクが生じやすい点に絞って確認することを挙げています。支援会社が、承認の設計を「安全の手段」としてだけでなく、「業務を止めない工夫」としても考えているかどうかは、実務経験の手がかりになります。最終的な判断者を誰にするかは、発注側が決める事項であり、支援会社はその決定を支える設計を提案する立場です。
5.4 監視、停止、記録：問題が起きたときに止められ、後から追えるか
エージェントは、稼働後も振る舞いが変わりうるため、監視と停止の仕組みが必要です。尋ねるべきは、何を監視するのか、異常をどう検知するのか、異常時に誰が、どの手順で停止するのか、停止したときに業務が止まらないようにどう代替するのか、という点です。代替の手順は、フォールバック（あらかじめ用意した代替の手順への切り替え）と呼ばれ、AIが使えない場合でも業務が続くようにするために重要です。
記録については、監査ログを解説した記事が、誰が、いつ、何をしたのかを後から追えるようにする記録であること、行為者、時刻、操作、対象、結果などを残すこと、記録を改ざんしにくくすること、保存期間は法令や社内の規程などに応じて決めることを整理しています。同記事はAIには触れていませんが、エージェントの操作の記録を考える際にも通じる考え方です。エージェントの場合は、これに加えて、どの依頼に対して、どの道具を、どの引数で呼び出し、どのような結果を得たのかを追えることが望まれます。
停止の条件は、事前に決めておくほど実効性が高まります。たとえば、禁止された操作の試行が一定の水準を超えたら承認を必須にする、費用が上限を超えたら高価なモデルの使用を絞る、といった条件を、発注側と支援会社が合意しておきます。運用の途中で条件を決めようとすると、問題が起きている最中の判断になり、冷静な合意が難しくなります。
6. 評価・品質保証とセキュリティ・ガバナンスは、提案書と質問でどう確認すればよいのか？
評価の質問集と回帰確認（変更の後も以前の品質が保たれているかの確認）の仕組み、想定外の入力への耐性の検証、データの取り扱いと権限、記録と変更管理のそれぞれについて、書面の回答と実際の運用の説明の両方で確かめます。
評価とセキュリティは、デモで見えにくく、かつ後から追加すると費用が大きくなりやすい分野です。そのため、選定の段階で、設計に最初から組み込まれているかを確認します。この章では、評価、検証、データの取り扱い、ガバナンスの四つの観点で整理します。
6.1 評価セットと回帰確認：品質を測り続ける仕組みがあるか
評価の中心は、実際の業務に近い質問や依頼の集まり（評価セット）と、変更のたびにそれを再実行して品質の低下を確かめる回帰確認（以前に動いていたものが、変更で壊れていないかを確かめること）です。AIエージェントの評価を扱った記事は、評価を最終的な文章の出来だけでなく、理解、計画、道具の使い方、結果といった一連の流れで見ること、実際の使われ方を反映した課題の集まりを用意すること、難易度別に弱点を見つけること、同じ課題を複数回実行して一貫性を見ること、測りやすい指標は自動化し自然さや確認の適切さは人が評価することを整理しています。
支援会社への質問は、次のようになります。評価セットは誰が、どのように作るのか。典型的な依頼だけでなく、曖昧な依頼や例外的な依頼も含めるのか。合否の基準は、どう決めるのか。評価セットは納品物として発注側に渡されるのか。変更のたびに再実行する仕組みはあるのか。人による評価と自動の評価をどう分担するのか。特に、評価セットを納品物に含めて自社に渡す提案は、内製化の観点からも価値があります。評価セットは、モデルを変えるとき、支援会社を変えるときにも使える資産だからです。
たとえばSYPのWebアプリとAIの統合設計の記事では、運用において、モデル、プロンプト（AIへの指示文）、参照データの版を記録して、品質が下がった原因をたどれるようにすること、禁止事項への違反、根拠の欠落、形式の崩れ、過度な断定などを対象にした固定の評価セットで回帰の確認を行うこと、停止条件をあらかじめ定めておくことが述べられています。評価を一度きりの検証ではなく、変更に対する継続的な確認として設計する考え方の例です。
6.2 想定外の入力や悪用への耐性：レッドチーミングなどの検証
通常の使い方での品質に加えて、想定外の入力や悪用に対してどう振る舞うかも確認が必要です。AIレッドチーミングを解説した記事は、AIレッドチーミングを、AIの弱点を事故の前に見つけるために、通常利用の外側で何が起こるかを意図的に試す評価と位置づけています。対象としては、有害な出力、もっともらしい誤り（ハルシネーション）、情報の漏えい、指示からの逸脱、外部の道具の悪用などが挙げられています。同記事は、結果をもとに修正し、モデルの更新や大きな設定の変更、データ源や道具の追加のたびに再度確認することも述べています。
支援会社には、「このような検証を実施するか」「誰が、どの観点で行うか」「発見された問題をどう記録し、どう直し、再確認するか」を尋ねます。大きな変更のときや、リスクの高い用途のときは、開発したチーム以外の目で確認することも有効です。ただし、すべての取り組みで大規模な検証が必要なわけではありません。リスクの大きさに応じて、検証の深さを変える考え方を示せるかが重要です。
6.3 セキュリティとデータの取り扱い：入力した情報はどう扱われるのか
セキュリティの質問は、入力した情報が、どこで処理され、保存され、誰が見られ、学習に使われるのかという、情報の流れを軸に整理すると漏れが減ります。ソフトウェアベンダーの評価の記事も、データの所有、保管場所、AIの学習への利用、削除を、データプライバシーの確認項目として挙げています。AXでは、外部のモデル提供者のサービスを経由することが多いため、支援会社と、モデルの提供者の二つの層について、契約上の取り扱いを確認する必要があります。
具体的には、入力した情報や出力が、モデルの学習に使われない取り決めになっているか、情報の保管場所と保管期間はどうなっているか、削除の依頼にどう応じるか、ログに個人情報や機密情報が含まれる場合にどう保護するか、開発や検証で本番のデータを使う場合のマスキング（見えないように加工すること）や管理はどうするか、を尋ねます。また、認証の取得や第三者の審査の有無も確認の手がかりになりますが、それらは対象の範囲と有効期限を確認する必要があり、認証があることがそのまま個別の取り組みの安全を保証するわけではありません。
6.4 ガバナンス：利用ルール、責任、記録、変更管理
ガバナンスとは、安全で持続的に進めるための管理の仕組みです。AXでは、AIの利用ルール、責任者、承認の流れ、記録、変更の管理が含まれます。支援会社に求めるのは、発注側が作るべきルールの草案づくりの支援、運用の中での記録の整備、モデルや設定の変更を管理する手順の提案です。ルールそのものを決めるのは発注側ですが、実務に落とせる形に整える支援は、経験のある会社が得意とする部分です。
変更管理は特に見落とされやすい点です。モデルの提供元による更新、プロンプトの修正、参照する文書の追加は、いずれも出力に影響を与えます。変更のたびに誰が承認し、どの評価を行い、記録を残すのか。この手順を提案に含めている支援会社は、運用の現実を理解していると考えられます。
7. 既存システム連携とシステム刷新、体制、継続運用と内製化支援は、どう比べればよいのか？
既存システムとの連携の設計、システム刷新との関係、提案者と担当者の一致、橋渡しの体制、稼働後の運用と知識移転の方法を、同じ観点で質問し、実績の語りではなく、具体的な手順の説明で比べます。
生成AIの仕組みが単独で動くことは少なく、多くの場合、既存の業務システムや文書管理の仕組みとつながって初めて価値が出ます。さらに、取り組みを支える体制と、稼働後の運用が整っていなければ、構築した仕組みは長続きしません。この章では、連携、刷新、体制、運用の四つの観点を扱います。
7.1 既存システムとの連携：読み取りから実行へ、段階を広げる設計か
既存システムとの連携では、AIがシステムの情報を読み取るだけなのか、更新や実行までするのかで、必要な設計の重さが大きく異なります。読み取りだけであれば、権限の整合と情報の鮮度が主な論点です。更新や実行を伴う場合は、二重に登録されないようにする仕組み、失敗したときの巻き戻し、承認の位置、システム側の制約との整合が加わります。
支援会社への質問は、次のとおりです。連携にはAPI（システム同士をつなぐ接続口）を使うのか、データベースを直接参照するのか、画面操作の自動化に頼るのか。連携先のシステムの権限は、利用者ごとにどう反映するのか。連携先のシステムが停止したり、応答が遅れたりしたとき、どう振る舞うのか。更新を伴う操作は、最初は提案にとどめ、段階的に広げる計画になっているのか。連携先のシステムの変更に追従する体制は、誰が担うのか。
連携は、既存システムに関する知識が支援会社側にあるか、発注側が提供するかによっても、進め方が変わります。既存システムの設計資料が不十分な場合、調査の作業が必要になり、その範囲を見積に含めるかどうかで費用が変わります。この点は、提案書の前提条件の欄に明記されているかを確認します。
7.2 システム刷新との関係：AXと基幹の更新を、一緒に見られるか
AXの取り組みは、システム刷新と無関係ではありません。古い構造が、データの取り出し、連携、自動化を妨げることがあり、AIの活用が進まない原因が基幹側にある場合もあるためです。たとえばSYPのレガシーモダナイゼーション（古い仕組みを現代の仕組みへ更新すること）のページでは、レガシーシステムを単に古いシステムではなく変化を妨げるシステムと位置づけ、現状把握・アセスメント、方針選定、段階的な実行、安定化・運用の四つのステップで進めることが示されています。同ページは、古い構造がAIの導入を妨げうることにも触れています。
選定の観点では、支援会社が、AXの取り組みと基幹システムの刷新の関係を、どう整理して提案しているかを見ます。刷新の計画がある場合、AIの仕組みが刷新の影響を受けるため、順序の提案が必要です。先に刷新を行うのか、並行するのか、AIの取り組みを先行させ、後で作り替える前提にするのか。それぞれの利点と注意点を説明できるかが、判断の手がかりになります。また、刷新や移行の際には、データの形式や権限の構造が変わるため、AI側の評価をやり直す必要があります。この再確認を計画に含めているかも確認します。
システムの移行では、業務を止めずに進めるための段階的な切り替え、切り戻しの手順、旧新の並行稼働といった考え方が一般に用いられます。AXの取り組みでも同様に、段階的に切り替える計画があるかを確認します。ただし、AXと刷新の両方を一社で担えることが常に最善とは限りません。担当を分ける場合は、境界での責任と情報の受け渡しを明確にすることが、より重要になります。
7.3 体制とコミュニケーション：提案する人と、作業する人は同じか
体制の評価で最も重要な確認は、提案の場にいる人と、実際に作業をする人が同じか、少なくとも連続しているかという点です。提案の質が高くても、契約後に担当が入れ替わると、提案の内容が実現されない可能性があります。担当予定の人の経歴、過去の経験、稼働の割合を示してもらい、可能であれば面談を求めます。
SIerの選び方を扱った記事は、規模や知名度、見栄えのよい提案書は弱い手がかりであり、PM（プロジェクトマネージャー）や中心となる担当者の質、再委託が見えて管理されているか、契約後に営業担当が不在になる危険などを確認すべきだとしています。同記事はまた、見積書を金額の表ではなく、案件の理解とスコープの定義の差が表れる資料として読むべきだとも述べています。同記事は、システム構築の事業者を案内する立場の記事でもあるため、自社の状況に引き写して読むことが大切です。
海外の拠点を活用する場合は、橋渡しの体制を追加で確認します。BrSE（ブリッジSE。日本側の要望と海外側の開発を橋渡しする技術者）やブリッジPMがどの程度の日本語と技術の理解を持ち、不在時の代行がどうなるか、時差のある会議体をどう運営するかです。たとえばSYPのオフショア開発のページでは、専任チーム、プロジェクト型、ハイブリッド型の三つの提供形態が示され、チームを確定する前に候補のエンジニアと面談でき、発注側の承認なしにメンバーが割り当てられることはないと述べられています。また、日本とベトナムの間をつなぐバイリンガルのPMや橋渡しの支援があると案内されています。このように、体制の組み方や面談の可否が公開されている場合は、確認の手がかりになりますが、実際の運用は個別に確かめる必要があります。
7.4 継続運用と内製化支援：稼働後の面倒を見る人と、自社に移す方法
AXの仕組みは、稼働後に、文書の更新、評価の再実行、モデルの変更への対応、利用者からの問い合わせ、費用の確認といった運用が続きます。そのため、継続運用の体制と、内製化の方針の二つを確認します。継続運用では、窓口はどこか、障害や品質低下の連絡と対応の手順はどうなるか、サービス水準（SLA。応答や復旧の目標を定めた合意）は設けられるか、定期的な報告はどのような内容かを尋ねます。
内製化支援では、自社の担当者が、どの作業をできるようになるのかを、具体的に確認します。たとえば、評価セットの更新、文書の追加と廃止、プロンプトの調整、利用状況の確認といった日常の作業を自社で行えるようにする計画があるか。そのための資料、研修、共同作業、レビューは含まれているか。知識の移転が完了したと判断する基準は何か。この基準が曖昧なままだと、移転の進捗が確認できず、外部への依存が続きやすくなります。
内製化を重視する一方で、すべてを自社で行う必要はありません。難しい調整や、専門性の高い作業を継続して外部に依頼する選択肢もあります。重要なのは、何を外部に残し、何を自社に移すのかを、意図して決めておくことです。決めていないと、依存の範囲が時間とともに広がり、見直しの機会を失いやすくなります。
8. RFPはどのような構成で書き、実装力を確かめる質問をどう整理すればよいのか？
RFPは、背景と目的、対象範囲、確かめたい実装力の質問、回答の様式、評価の方法、契約の条件を同じ順序で示し、各社が同じ条件で比べられる回答を出せる形に整えます。
RFPは、提案を依頼する側が、目的と条件を示し、各社から比較しやすい形で提案を受けるための文書です。ここで書くべきことは、自社が何を望み、何を前提とし、どう評価するかであり、実装の方法そのものを細かく指定することではありません。方法まで指定してしまうと、各社の工夫や経験の差が見えなくなります。一方で、前提が書かれていなければ、各社が異なる想定で提案を作り、比較ができません。このバランスが、RFPの書き方の要点です。
8.1 調達文書の使い分けと、RFPの章立て
調達の文書には、RFI（情報提供依頼書。市場や各社の情報を集めるための文書）、RFQ（見積依頼書。仕様が定まったものの価格を比べるための文書）、RFP（提案依頼書。目的を示し、提案の内容を比べるための文書）があります。RFPを解説した記事は、市場を把握する段階ではRFI、仕様が決まった後に費用を比べる段階ではRFQ、最終候補に対して技術的な進め方や体制を含む包括的な提案を求める段階ではRFPと、使い分ける流れを紹介しています。
AXの支援会社の選定では、取り組みの内容が固まりきっていないことが多いため、最初に広く情報を集めるRFIを行い、そのうえで候補を絞ってRFPを出す二段階が考えられます。ただし、候補が少数で、取り組みの範囲も明確な場合は、RFPから始めることもあります。いずれにしても、RFQだけで比べると、AXでは「何を作るか」自体の提案が含まれるため、価格の比較が成り立たない場合があります。
同記事はRFPの内容として、プロジェクト概要、業務・システム概要、機能要件・非機能要件、開発条件、提案依頼事項、提案手続き、評価、契約事項といった構成を示しています。AXの場合、これに沿いながら、背景と目的、対象業務とデータ、守るべき条件（情報の扱い、権限、規程）、確かめたい実装力に関する質問、体制と運用に関する依頼、回答の様式と手続き、評価の方法、契約に関する前提、という順に組むと整理しやすくなります。
8.2 実装力を確かめる質問を、評価軸ごとに整理する
RFPの質問は、評価軸と対応させて整理します。軸ごとに、何を尋ね、どの形式で回答してもらい、どの資料の添付を求めるのかを決めます。回答の形式は、自由な文章、はい・いいえに根拠を添える形、図や表、実績の概要、サンプル資料などから、質問の性質に合わせて選びます。はい・いいえで答えられる質問だけを並べると、各社が「対応可能」と答え、差がつきません。そのため、はい・いいえの質問には「どのように」「どの程度」という説明を必ず添えてもらいます。
質問の数は、多ければよいわけではありません。多すぎると、回答する側も評価する側も負担が増え、本当に重要な点が埋もれます。重みの高い軸には質問を厚く、重みの低い軸には簡潔に、というように、評価軸の重みと質問の量を合わせます。また、回答の分量にも目安を示すと、文章量の差が評価に影響することを避けられます。
質問の書き方にも注意が必要です。たとえば、「RAGの権限制御に対応していますか」という質問では、各社がはいと答えます。「利用者の権限に応じて、回答の素材となる文書を絞る方式を、どの段階で、どの仕組みで実現するか。想定される限界も含めて説明してください」と書くと、答えの差が出ます。限界の説明を求めることは、実際の経験に基づく回答を引き出す工夫になります。
8.3 回答様式をそろえ、書きすぎず、書かなさすぎない
比較しやすくするには、回答の様式を指定します。章立て、質問番号に対応した回答、見積の内訳の様式、体制の表の様式などをそろえます。RFPの記事は、情報の過不足を避けること、比較しやすい様式にすること、評価基準を明確にすること、内部で事前に調整することなどを実務上の注意として挙げています。
書きすぎと書かなさすぎの判断は、「自社が決めるべきこと」と「支援会社の提案に委ねること」の線引きに対応します。自社が決めるべきことは、目的、守るべき条件、評価の方法、予算の枠の考え方、スケジュールの制約です。提案に委ねることは、実装の方式、モデルや構成の選択、進め方の工夫です。ただし、委ねる場合でも、選択の理由の説明を求めることで、比較の材料にできます。
予算については、枠を示すか示さないかの判断があります。枠を示すと、各社がその範囲で現実的な提案を作りやすくなる一方、枠に合わせた提案ばかりになる可能性があります。示さない場合は、提案の幅が広がりますが、実現が難しい提案も混ざります。いずれの場合も、費用の内訳と前提を明示してもらうことが、比較のためには欠かせません。
8.4 質疑、守秘、公平性：提案の前後の進め方
RFPを出した後は、質疑の機会を設けるのが一般的です。質疑の内容と回答は、全候補に共有すると、情報の差による不公平を避けられます。ただし、各社固有の工夫に関わる質問は、共有の範囲を考える必要があります。質疑の期間、方法、回答の期限を、RFPに明記します。
機密情報の取り扱いにも配慮が必要です。RFPの段階では、NDA（秘密保持契約）を結んだうえで、必要な範囲の情報を開示します。実際の業務文書や顧客の情報は、提案の段階では渡さず、匿名化した例や、構造だけを示した資料にとどめるのが一般的な配慮です。PoCの段階で初めて実データに近いものを扱う場合は、その取り扱いを別途取り決めます。
提案の後は、書面の評価に加え、面談やデモを行います。このとき、評価の観点を事前に決めておき、全社に同じ質問をします。面談の記録は、評価者が独立して点数を付けた後に、根拠とともに共有する運用が、印象に引きずられる影響を和らげます。
9. 比較表とスコアカードは、どう作り、どう読めばよいのか？
必須条件のゲート（通過の条件を確かめる関門）と、重み付きの加点項目、根拠の欄を持つスコアカードを事前に作り、評価者が独立に採点してから合議し、点数の合計だけでなく、弱い軸と不確実な点を併せて読みます。
スコアカードは、候補を同じ軸と同じ基準で採点し、比較するための表です。点数にすることで、印象の議論を減らし、判断の過程を記録に残せます。ただし、点数は便利な反面、数字が独り歩きして、実際の違いを覆い隠すこともあります。本章では、作り方と、読み方の注意を整理します。
9.1 比較表の骨格：ゲート、重み付きの加点、根拠の欄
スコアカードは、三つの部分で構成します。最初に、必須条件のゲートです。ここでは、満たすか否かを確認し、満たさない候補は以降の採点に進みません。次に、評価軸ごとの加点です。軸ごとに重みを置き、各候補を一定の尺度で採点します。最後に、根拠の欄です。点数の理由を、どの資料や回答に基づくのかを書きます。
尺度は、粗いほうが運用しやすい傾向があります。たとえば、「要件を十分に満たす」「一部に不足がある」「不足が大きい」「確認できない」のように、数段階の言葉で定義し、それぞれに点を対応させます。細かい点数にすると、評価者ごとの差が大きくなり、その差が実力の差を反映しているのか、評価者の癖なのかが区別できません。「確認できない」という区分を設けることも大切です。確認できなかったことを低い点と同じに扱うか、保留として別に扱うかは、あらかじめ決めておきます。
9.2 仮の数字で計算してみる
仕組みを理解するために、仮の数字で計算してみます。ここでは評価軸を三つだけ取り、重みを、戦略・ユースケースが二、データとRAGの実装が三、セキュリティとガバナンスが三とします。三つの候補を、それぞれ五段階で採点し、重みを掛けて合計します。
この例では、候補Aは戦略の点数が高く、候補Bは実装の点数が高く、候補Cは安全性の点数が高い、という具合に、特徴が分かれるように設定してあります。合計点は近い値になります。このとき、合計点の差だけで決めることは適切ではありません。合計が近いのは、軸ごとの強みと弱みが相殺されているためであり、自社にとって弱い軸の影響が大きいのか小さいのかは、別途考える必要があるからです。
※数値は説明のための仮定であり、実際の評価や特定の企業の実績を示すものではありません。
9.3 点数の限界と、読み方の注意
点数には、いくつかの限界があります。第一に、採点は評価者の判断であり、評価者の人数が少ないと偏りが生じやすいことです。可能であれば複数の評価者が独立に採点し、差が大きい項目は理由を話し合います。差が大きいということは、その項目の情報が不足しているか、解釈が分かれているかを示しており、追加の質問で確認すべき手がかりになります。
第二に、重みの設定に結果が左右されることです。重みを少し変えただけで順位が入れ替わる場合、それらの候補は実質的に拮抗していると読めます。そのような場合は、重みを何通りか変えて結果を確かめ、順位が安定しているかを見ます。順位が安定しない場合は、点数以外の要素、たとえば体制の相性やPoCでの手応えを判断に加えます。
第三に、点数に表れにくい要素があることです。担当者との相性、質問への誠実な対応、不確実な点を正直に示す姿勢などは、点数にしにくいものの、長い関係では重要です。これらは、面談やPoCの記録に所見として残し、点数と併せて議論します。先に挙げたSIerの選び方の記事が、提案の質問の質やリスクを開示する姿勢を見るよう勧めているのも、この点に通じます。
9.4 評価の運用：評価者、独立採点、合議、記録
評価の運用では、まず評価者を決めます。事業部門、情報システム部門、情報セキュリティ部門、調達部門など、異なる視点の人を含めます。次に、各評価者が他の人の点数を見ずに採点します。その後、点数の差が大きい項目について話し合い、必要に応じて追加の質問を行い、点数を見直します。最終的な点数、根拠、合議の結果は、記録として残します。
記録は、選定の理由を社内で説明するためだけでなく、選定後の運営にも役立ちます。評価の段階で弱い軸として挙がった項目は、契約後に重点的に確認し、改善を求める事項にできるためです。選定の記録を契約後の運営に引き継ぐという発想は、選定を一度きりの出来事ではなく、関係の始まりと捉える見方につながります。
10. PoCでは、何を成功条件とし、どの基準で拡大か撤退かを決めればよいのか？
PoCは技術の検証であると同時に支援会社の進め方を確かめる機会として位置づけ、成功条件と撤退基準を開始前に書き、範囲・データ・評価者を絞って設計し、結果を拡大、修正、中止の三つの判断につなげます。
書面の提案とヒアリングだけでは、実装力と協働のしやすさは完全には分かりません。そのため、候補を絞った後にPoCを行い、実際の業務に近い条件で確かめる進め方が有効です。AXのロードマップにおけるPoCの設計は別の記事で扱っているため、ここでは、支援会社を見極める観点に絞って整理します。
10.1 PoCで見るのは、成果物だけではなく、進め方である
PoCの目的は二つあります。一つは、技術的に目的を達成できる見込みを確かめることです。もう一つは、その支援会社と一緒に進めることが適切かを確かめることです。後者は見落とされがちですが、選定の観点では重要です。具体的には、課題の理解の速さ、質問の質、進捗の報告の透明性、問題が見つかったときの報告の姿勢、依頼の変更への対応、発注側の担当者との協働のしやすさです。
特に、結果が良くなかったときの報告の仕方は、支援会社の誠実さが表れる場面です。うまくいかなかった点、その原因の仮説、次に試すことを率直に示す会社は、本番でも問題を早く共有してくれると期待できます。反対に、都合のよい結果だけを強調する報告は、本番での問題の発見が遅れる懸念を示します。PoCの結果が悪い場合に、どう振る舞うかを観察できること自体が、PoCの価値の一つです。
10.2 成功条件と撤退基準を、開始前に書く
PoCの設計では、成功条件と撤退基準を、開始の前に書きます。業務理解不足がAI活用を失敗させる理由を扱った記事は、PoCが都合のよい条件で行われがちであること、合格の水準と撤退の水準を先に決めることでPoCが次の判断につながること、欠損データ、例外、承認の流れといった本番の条件を早めに含めることを述べています。
成功条件は、業務の指標と、品質の指標の組み合わせで書きます。業務の指標は、作業にかかる時間、確認の手間、手戻りなどです。品質の指標は、回答の正確さ、根拠の提示、権限の違反の有無、禁止事項への違反の有無などです。撤退基準は、たとえば「重大な誤りが許容の水準を下回らない場合」「権限の違反が確認された場合」「利用者が業務で使えないと判断した場合」といった形で、言葉にしておきます。基準を事前に置かなければ、期待が大きい取り組みほど「もう少し続ければ」という判断になりやすく、見極めの機会が失われます。
複数の会社にPoCを依頼する場合は、条件を同じにします。同じデータ、同じ評価セット、同じ期間、同じ評価者で行わないと、結果の差が会社の差なのか、条件の差なのかが区別できません。費用負担も事前に決めます。有償で行うか、一部無償か、選定の条件に含めるかは、会社の規模や案件の性質、社内の規程によって異なります。
10.3 範囲、データ、評価者を絞って設計する
PoCの範囲は、小さく、しかし本番の難しさを一部含むように設計します。一つの業務、限られた利用者、承認済みの文書に絞りながら、権限の制御、根拠の提示、評価の仕組みといった基本構造は含めます。社内RAG・AIエージェント開発の費用と進め方の記事は、最初の検証では費用を抑えるために評価や権限の設計を削るのではなく、利用者、文書、業務の対象範囲を絞るのが望ましいことを述べています。これは、PoCを選定の材料として使う観点からも妥当な考え方です。権限や評価を省いた簡易な試作では、本番で必要になる実装力が見えないためです。
データは、実際の業務に近い文書や質問を使いますが、機密性の高い情報は、取り扱いの取り決めの範囲で扱います。難しい場合は、構造を保った加工済みのデータを使うことも考えられます。評価者は、業務を知る現場の担当者を含めます。支援会社の担当者だけで評価すると、都合のよい解釈が入る余地が生じるためです。
PoCに必要な発注側の稼働も、見積もっておきます。評価用の質問の用意、回答の判定、フィードバックには、現場の時間が必要です。この稼働が確保できない場合、PoCの結果の信頼性が下がります。
10.4 結果の読み方と、次の判断：拡大、修正、中止
PoCの結果は、成功条件に照らして、拡大、修正、中止の三つの判断につなげます。拡大は、成功条件を満たし、重大なリスクが見つかっていない場合に、範囲を広げて次の段階に進む判断です。修正は、一部の条件を満たさないが、原因が特定でき、改善の見込みがある場合に、設計を見直して再度確かめる判断です。中止は、撤退基準に該当する場合に、取り組みの範囲や進め方を見直す判断です。
どの結果でも、PoCは価値を生みます。拡大しないという判断も、投資を適切に止めたという成果です。また、支援会社の選定という観点では、PoCの結果が良くても、進め方の相性が合わないと感じた場合は、それも判断の材料にします。逆に、技術的な結果が一部不足していても、原因の分析と改善の提案が的確であれば、その会社と進める価値があると判断することもあります。そのため、点数だけでなく、PoCでの観察の所見をスコアカードに加え、最終の合議に臨みます。
11. 見積の比べ方と、契約形態・知的財産・データ・再委託は、どう整理すればよいのか？
見積は費用の決定要因と前提を同じ条件にそろえて比較し、契約は形態ごとの責任の違いを理解したうえで、成果物の帰属、データの取り扱い、再委託、終了時の対応を文書で確認します。
見積の金額は、提案の範囲と前提によって大きく変わるため、総額だけを並べても比較になりません。契約についても、形態や条件によって、費用が変わったときの扱い、成果物の権利、問題が起きたときの責任が異なります。この章では、数字そのものではなく、構造と確認点を整理します。本記事は法的な助言ではなく、契約の具体的な条項は、法務の専門家と確認する必要があります。
11.1 AXの費用を左右する決定要因
AX関連の費用を左右する主な要因は、対象とするデータと文書の量と状態、権限の細かさ、検索と評価の作り込み、既存システムとの連携の範囲と更新の有無、利用する経路、ガバナンスと監視の水準、体制の規模と期間などです。たとえばSYPの社内RAG・AIエージェント開発の費用と進め方を扱った記事では、RAGの費用はAIモデルの料金そのものよりも、データの準備、権限の管理、検索と評価、システム連携、利用の経路、ガバナンスと監視といった要因で左右されることが整理されています。同記事は、読み取りだけの連携に比べ、更新を伴う連携には承認や重複防止、巻き戻しが必要になり費用が増えること、運用では文書の再取り込みや評価の再実行などの継続的な費用が生じることも述べています。
これらの要因は、見積の比較で、どの要因が同じ条件で見積られているかを確認する手がかりになります。ある会社の見積が低いのは、権限の細かさを簡略にしているためかもしれませんし、評価の作り込みを含めていないためかもしれません。単に効率が高いのではなく、範囲が異なる可能性を、まず疑います。
11.2 見積を同じ条件にそろえて比較する
見積の比較では、総額の前に、前提と内訳を見ます。前提には、対象とする文書やデータの範囲、利用者の規模、評価の範囲、連携するシステムの数、体制の人数と期間などがあります。内訳には、構想と設計、構築、評価、連携、教育、プロジェクト管理、稼働後の運用などがあります。これらを同じ項目に並べ替えて、各社の見積を比較表にします。
見積の構造は、一般に、体制の人数と期間から工数を求め、それに役割ごとの単価を掛ける形で作られます。この場合、工数の前提が違えば、総額は大きく変わります。人数や期間が示されていない見積は、比較が難しくなります。また、海外の拠点を活用する場合は、為替の影響、橋渡しの管理工数、時差による調整の手間も確認します。単価が低く見えても、管理や調整の工数が別に必要になれば、総額は変わります。
さらに、見積に含まれていないものを確認します。稼働後の運用費用、モデルの利用料、評価の再実行、文書の更新、教育、追加の要望への対応は、含まれているか、別途か、範囲外か。変更が生じた場合の費用の決め方はどうか。含まれていない項目は、後で追加の費用として現れる可能性があります。SIerの選び方の記事が、見積を総額ではなく内訳、前提、除外事項で比べるよう勧めているのは、この理由によります。
11.3 契約形態：請負、準委任、専任チームの違い
契約形態は、一般に、成果物の完成を約束する請負契約、作業の遂行を委託し成果の完成そのものは約束しない準委任契約、一定の人員を継続的に確保する専任チーム型（ラボ型）などに分けて語られます。ラボ型と請負型を比較した記事は、専任チームは人月契約で、変更に柔軟に対応しやすい一方で、発注側が進行管理の責任を負い、成果が保証されないことが多いと述べています。請負型は、成果物が明確で範囲が限られる場合に向き、範囲外の変更には追加の契約や費用が必要になると整理しています。また、両者を組み合わせる方法も紹介しています。
AXの場合、検証の段階では、結果が事前に確定しにくいため、請負で成果物を固定するよりも、準委任や専任チームで試行を重ねる形が適することがあります。一方で、設計が固まり、範囲が明確になった部分は、請負で成果物と検収の条件を定めるほうが、費用の見通しを立てやすい場合があります。段階によって契約形態を切り替える、あるいは組み合わせる選択肢も考えられます。いずれの場合も、検収の条件、変更の扱い、責任の範囲を、契約の前に明確にします。
11.4 知的財産、データ、再委託の責任分担
契約で最も確認が必要なのは、成果物の知的財産、データの取り扱い、再委託の三つです。知的財産では、納品された設計書、ソースコード、プロンプト、評価セット、学習や調整のために作られたデータの権利が、誰に帰属するのかを確認します。支援会社が持つ既存の部品や道具は支援会社に残り、発注側には利用の権利が与えられる形がよく見られますが、その範囲と、契約終了後の利用の可否を明確にします。
データについては、発注側が提供したデータの所有、利用目的の限定、保管場所と期間、返却と消去、モデルの学習への利用の禁止、ログの扱いを確認します。再委託については、禁止するのか、事前の承認を条件に認めるのか、再委託先にも同等の義務を課すのか、再委託先を発注側が把握できるのかを確認します。前述のソフトウェアベンダー評価の記事も、契約上の確認事項として、SLA、サポート範囲、データの所有と返却、AI利用、価格、終了時の条件、責任の境界を挙げています。
終了時の対応も大切です。契約が終わるとき、成果物、評価セット、ログ、設定、手順書が自社に引き渡されるか。データが消去され、その確認ができるか。引き継ぎへの協力の範囲はどこまでか。これらを契約に含めておくと、支援会社を変更する際の障壁が下がり、特定の会社への依存を避けやすくなります。なお、これらの確認事項は一般的な整理であり、実際の契約では、自社の法務部門や専門家と条項を確認してください。
12. 危険信号と失敗パターンには、どのようなものがあり、どう扱えばよいのか？
危険信号は、提案と説明、体制、契約と運用に表れる兆候として整理し、一つで即座に除外するのではなく、確認の質問に変えて答え方を見ることで、失敗パターンを事前に避けやすくなります。
選定の段階で見落とした問題は、契約後に費用と時間を伴う形で表れます。そこで、選定の過程で気づきやすい兆候を、あらかじめ一覧にしておくと便利です。ただし、危険信号はあくまで確認を深めるきっかけであり、一つ当てはまったからといって、その会社が不適切だと断定できるものではありません。事情があって説明がつく場合もあるため、確認の質問を用意して、答え方から判断します。
12.1 提案と説明に表れる危険信号
提案と説明の段階で気づきやすい兆候には、次のようなものがあります。第一に、成果や精度を断定的に述べ、その根拠や条件が示されていないことです。「高精度」「どんな文書にも対応」といった表現は、何に対してどの条件でなのかが示されなければ、比較の材料になりません。第二に、デモの見栄えが中心で、例外、権限、評価、運用についての説明が薄いことです。第三に、課題の確認の質問が少なく、最初から特定の製品や構成を前提にしていることです。
第四に、リスクや限界を述べないことです。生成AIには、もっともらしい誤りや、出力の揺れといった性質があります。これらに触れず、全般的に可能であるかのように語る提案は、現実の運用を経験していない可能性を示します。第五に、他社の実績を述べるだけで、その実績の中で自社が担った役割や、直面した問題と対応が具体的に語られないことです。前述のSIer選びの記事は、提案書が一般論ばかりで実行計画やリスクの議論がないこと、ヒアリングが機能の確認だけで例外や運用に触れないこと、見積の前提や除外が曖昧なことを注意すべきサインとして挙げています。
確認の質問は、兆候ごとに用意します。たとえば、精度を断定している場合は「その精度は、どのデータとどの評価方法で測ったものか。条件が変わったときにどう変化すると考えるか」と尋ねます。リスクに触れない場合は「この取り組みで、最も懸念している失敗は何か。どう検知し、どう対応するか」と尋ねます。答えが具体的であれば、兆候は杞憂であった可能性が高く、答えが曖昧であれば、懸念が裏づけられます。
12.2 体制、契約、運用に表れる危険信号
体制に関する兆候としては、提案の場の担当者と作業の担当者が異なり、会わせてもらえないこと、担当者の経歴や稼働の割合が示されないこと、再委託の有無や範囲が明確でないこと、不在時の代行が考えられていないことなどがあります。契約に関する兆候としては、成果物の権利やデータの取り扱いについての説明を避けること、終了時の引き継ぎに言及がないこと、変更の扱いが曖昧なこと、費用の追加の条件が不明確なことなどがあります。
運用に関する兆候としては、稼働後の窓口や対応の手順が示されないこと、評価や監視の仕組みが含まれていないこと、知識の移転の計画がなく、特定の担当者だけが仕組みを理解する構成になっていること、ブラックボックス化の恐れがあることなどです。ブラックボックス化とは、中身が自社から見えず、変更も確認もできない状態を指します。仕組みの中身が文書として残らず、評価セットも渡されない場合、後から会社を変更することが難しくなり、依存が固定化しやすくなります。
兆候の多くは、一つひとつは小さく見えます。しかし、複数が重なると、問題が起きたときの対応力が弱いことを示します。重なりの度合いを、スコアカードの根拠欄に記録しておくと、合議の際に議論の材料になります。
12.3 AXの取り組みで典型的に見られる失敗パターン
選定を誤った場合に起こりやすい失敗パターンは、いくつかに整理できます。一つ目は、デモ止まりのPoCです。試作は動くものの、権限、例外、評価、運用が整わず、本番に進めない状態です。二つ目は、権限や情報管理の後回しです。稼働の直前になって、情報の漏えいの懸念が見つかり、設計の作り直しになる場合があります。三つ目は、評価の不在です。品質が良いのか悪いのかを示す基準がなく、改善の判断ができません。
四つ目は、特定の会社への依存です。仕組みの中身や評価セットが自社に残らず、支援会社を変えられなくなる状態です。五つ目は、費用の想定超過です。利用量の増加や、運用で必要になる作業が見積に含まれておらず、稼働後に費用が膨らむものです。六つ目は、範囲の拡大です。要望が次々に追加され、当初の目的が曖昧になり、成果が見えなくなる状態です。七つ目は、既存システムや刷新との不整合です。連携や基幹システムの更新が考慮されず、AIの仕組みが孤立したり、更新で動かなくなったりします。
これらの失敗パターンの多くは、選定の段階での確認で、ある程度防ぐことができます。デモ止まりは、PoCの設計と評価の確認で。権限の後回しは、質問集と設計の確認で。評価の不在は、評価セットの納品の確認で。依存は、契約と内製化支援の確認で。費用の超過は、見積の前提と運用費用の確認で。範囲の拡大は、変更管理の確認で。不整合は、連携と刷新の関係の確認で。このように、失敗パターンと確認項目を対応させておくことは、選定の質問を設計する際の手がかりになります。
12.4 危険信号を、除外の理由ではなく確認の入口として使う
危険信号を機械的に除外の理由にすると、実際には優れた会社を逃す可能性があります。たとえば、経験は豊富でも、提案書の書き方が簡潔であるために、詳細が示されていないだけかもしれません。逆に、危険信号がまったく見当たらない提案は、書き方が巧みなだけで、実装力は別かもしれません。したがって、危険信号は、どの質問を追加するかを決める入口として使い、答えの具体性、根拠の提示、率直さを見て判断します。
また、危険信号は、自社の側にも当てはまることがあります。自社の要件が曖昧、担当者が確保できていない、データの整備が遅れているなどの状態は、支援会社の側から見れば、実施の難しさを示す兆候です。自社側の準備状況も、同じ点検表で見直すと、選定の前に直せる点が見つかります。
13. 選定後のオンボーディングでは、最初の期間に何を決め、どう運営すればよいのか？
契約後の最初の期間に、体制と連絡の方法、権限と環境の受け渡し、前提の確認、小さな成果の確認、選定の記録の引き継ぎを順に行い、定期的な見直しで関係を調整し続けます。
支援会社を選んで契約した後は、取り組みの成否は立ち上げの運営に左右されます。選定の段階で確認した内容が、実際の運営に引き継がれていなければ、確認の効果が失われます。本章では、選定後の立ち上げの要点を整理します。
13.1 契約直後に立ち上げる：体制、連絡、意思決定の場
契約直後に行うべきことは、体制と連絡の方法、意思決定の場を明確にすることです。発注側の責任者、現場の担当者、情報システムとセキュリティの窓口、支援会社の責任者、実務の担当者、橋渡しの担当者の名前と役割を、一覧にします。連絡の手段、定例会議の頻度と議題、緊急時の連絡先、意思決定の場と権限を決めます。意思決定の場では、誰が最終的に決めるのか、判断に迷うときの上位への報告の経路（エスカレーション）はどうするかも定めます。
あわせて、選定の記録を支援会社と共有します。評価の過程で挙がった弱い軸や、確認した事項、PoCでの所見は、運営の中で重点的に確認すべき項目になります。選定の記録を、発注側だけが持つのではなく、共通の認識として整理しておくと、後の議論が円滑になります。
13.2 最初の期間の運営：前提の確認から、小さな成果まで
最初の期間は、前提の確認、範囲の再確認、小さな成果の確認という順に進めると、大きな食い違いを早い段階で見つけやすくなります。前提の確認では、選定の段階で書面にした前提が、実際の業務やデータに照らして正しいかを確かめます。範囲の再確認では、含めるものと含めないものを、双方で再度合意します。小さな成果の確認では、限られた範囲で動く最初の成果を、評価の仕組みとともに確認します。
最初の期間は、双方が互いの進め方を学ぶ期間でもあります。報告の形式、質問の仕方、判断の速さの違いは、実際に進めてみないと分かりません。そのため、最初の期間の終わりに、進め方の振り返りを行います。連絡の遅れ、資料の分かりにくさ、判断待ちによる停滞などを共有し、運営を調整します。この振り返りを軽く扱わず、改善の記録を残すことが、長期の関係の質を高めます。
13.3 環境、データ、権限の受け渡しを、決めた手順で行う
環境、データ、権限の受け渡しは、選定の段階で確認した方針に沿って、手順を決めて行います。支援会社の担当者への権限の付与は、必要最小限の範囲で、申請と承認の記録を残して行います。データの受け渡しは、情報の区分に応じて、方法、保管場所、期間、消去の手順を決めます。支援会社が外部のサービスを使う場合は、その利用の可否と条件を、事前に確認します。
担当者が入れ替わる際の権限の削除も、立ち上げの時点で手順化しておきます。取り組みが長くなるほど、人の入れ替えは避けられません。入れ替えのときに、権限の付与と削除、引き継ぎ、記録の更新が確実に行われる運営は、情報管理の信頼性を保つ基盤になります。
13.4 定期的な見直しと、内製への移行計画
立ち上げが一段落した後も、定期的な見直しの場を設けます。見直しの内容は、成果と品質の確認、費用の確認、リスクと課題の確認、体制の確認、そして内製への移行の進捗です。移行の進捗は、選定の段階で決めた知識移転の基準に照らして確認します。自社の担当者が、どの作業をできるようになったか、まだ外部に依存している作業は何か、次に移すものは何かを、見える形にします。
見直しの結果、支援会社との関係を調整する場合もあります。範囲の変更、体制の見直し、契約形態の変更などです。さらに、評価や運営の状況によっては、支援会社の変更も選択肢になります。その際に、評価セット、設計書、手順書、ログが自社の手元にあり、引き継ぎが可能な状態であれば、変更の負担を小さくできます。選定の時点で、こうした出口を意識しておくことが、結果として、関係を良好に保つ力になります。
まとめ
本記事では、AX推進支援会社を、会社名の順位ではなく、比較の枠組みで選ぶ方法を整理しました。要点は次のとおりです。
- 支援会社の類型は、コンサルティング型、SIer型、AI専門型、内製支援型、海外拠点を活用する型などで整理できますが、看板ではなく、構想・実装・運用のどこに経験と体制があるかで見分けます。
- 依頼の前に、目的、対象業務、データ、体制、制約を整理し、判断と責任は自社に残して、作業と専門知識を分担する線引きを決めます。
- 評価軸は九つに整理し、必須条件と加点条件に分け、重みは提案を見る前に決めて記録します。実装力は、RAGの権限・評価・更新、エージェントのガードレール・承認・監視、モデル選定とコスト管理の質問で確かめます。
- RFPで質問を軸ごとに整理し、回答の様式をそろえ、スコアカードで独立に採点し、点数の合計だけでなく弱い軸と不確実な点を併せて読みます。
- PoCでは、成功条件と撤退基準を開始前に書き、範囲・データ・評価者を絞り、技術だけでなく進め方も見極めます。
- 見積は前提と内訳をそろえて比べ、契約では知的財産、データ、再委託、終了時の引き継ぎを確認し、危険信号は除外の理由ではなく確認の質問に変えて使います。
支援会社の選定は、一度の比較で終わる作業ではありません。選定の記録を契約後の運営に引き継ぎ、定期的に見直し、内製への移行を進めることで、選定の効果は長く続きます。個別の案件の判断は、自社の規程、扱う情報の性質、専門家の意見を踏まえて行ってください。
