結論:発注側のベンダー選定基準に「AI認定エンジニアの有無」と「AI前提の開発体制」を入れる時期に来た
Anthropicは2026年6月11日、世界70カ国・約11万5,000人の従業員を擁するグローバルITサービス大手DXC Technologyとの複数年提携を発表した。柱は人材だ。DXCは既存の開発チームから数万人規模のエンジニアをAnthropic Academy経由で認定し、「Claude認定のフォワードデプロイド(前線配置)エンジニア」として顧客組織に直接配置する。銀行・航空・保険・製造・政府機関といった顧客に、AI前提の開発体制を持ち込む座組みである。
数字も強烈だ。DXCが2026年4月に立ち上げたエンジニアリング基盤「DXC OASIS」について、「コードの95%超をClaudeが生成」「ソフトウェア開発を約10倍高速化」という数値が示されている。ただしここは正確に読む必要がある。これらはDXCが自社利用データから推定した自社公表値であり、第三者検証された業界標準値ではない。それでも、大手SIerが「人月の手書き開発」ではなく「AIがコードの大半を書き、人が設計と検証を担う」体制を公式な売り文句にした事実は、市場の地殻変動を示している。
発注側企業にとっての意味は明確だ。システム開発の見積もり・体制・単価の前提が、ベンダーによって最大10倍レベルで割れる時代に入る。「AIをどう使って開発するか」を語れないベンダーと、認定制度・統制基盤まで備えたベンダーが同じ相見積もりに並ぶ。選定基準を更新しないまま発注すれば、価格でも品質でも損をする側に回る。
押さえるべき1点:次のシステム開発の相見積もりでは、「AIによるコード生成を開発プロセスのどこで・どの統制のもとで使うか」を全ベンダーに必ず質問すること。回答の質がそのままベンダーの実力差になる。
提携の骨子:何が発表されたか
Anthropicの発表から確認できる内容を整理する。
| 項目 | 内容 |
|---|---|
| 提携形態 | 複数年のグローバル提携 |
| 人材 | 数万人規模の「Claude認定フォワードデプロイドエンジニア」を育成・顧客組織に配置 |
| 認定 | Anthropic Academyで認定。DXCは独自カリキュラムを追加実装 |
| 開発基盤 | DXC OASIS(2026年4月ローンチ)。現在50社超のDXC顧客に展開 |
| 公表数値 | コードの95%超をClaudeが生成・開発速度約10倍(DXCの自社利用データに基づく自社公表値) |
| 対象顧客 | 銀行・航空会社・保険会社・製造業・政府機関など |
| DXC規模 | 従業員約11万5,000人・70カ国 |
注目は「フォワードデプロイド(前線配置)」という言葉だ。従来のSIerの納品型・常駐型と異なり、AI活用の専門人材が顧客組織の中に入り、業務とAIの接続そのものを設計するモデルを指す。AI導入の成否が「モデルの性能」ではなく「業務への組み込み方」で決まることを、SIer側が認めた構図といえる。
なお同じ6月11日、日本ではNECとAnthropicが三井住友FGなど金融8社とのAI実装協業を発表している。本稿がグローバルSIer側の供給再編を扱うのに対し、日本の発注側・利用側の動きはNEC×Anthropic×金融8社の解説記事で整理した。同じ日に供給側と需要側の両方が動いた、という対で読むべきニュースだ。
「95%超・約10倍」をどう読むか:自社公表値の取り扱い
この数値を鵜呑みにするのも、誇張と切り捨てるのも、どちらも実務的ではない。
まず前提として、95%超・約10倍はDXCが自社のOASIS利用実績から推定した値であり、測定条件(対象プロジェクトの種類・規模・「生成」の定義・比較基準)は公表情報からは検証できない。新規コードの初稿生成率と、設計・レビュー・テスト・保守を含む開発全体の生産性は別物であり、外部がそのまま自社の見積もりに適用できる数字ではない。
一方で、方向性自体は他社データとも整合する。AIコーディング支援の普及で開発工程の生産性が大きく変わりつつあることは、最新世代モデルの能力向上(Claude Fable 5の解説)からも裏づけられる。グローバルSIerが看板数値として掲げた以上、競合他社も追随し、「AI前提の開発単価・納期」が相見積もりの土俵になるのは時間の問題だ。
発注側が取るべき態度はこうだ。ベンダーの公表値は「質問の出発点」として使う。「95%・10倍」を主張するベンダーには測定条件と品質担保の方法を、何も主張しないベンダーにはAI活用の方針そのものを問う。回答できないベンダーとの契約は、2026年以降の単価競争で割高な買い物になるリスクが高い。
発注側のベンダー選定チェックリスト:AI開発体制を見極める6問
相見積もり・RFPの段階で、次の6問を全候補に投げることを勧める。
- 開発プロセスのどの工程で、どのAIツール・モデルを使うか——「使っている」だけでなく工程別の使い分けを答えられるか。
- AI生成コードの品質担保はどうするか——レビュー体制・テスト戦略・静的解析など、人の検証プロセスが設計されているか。
- AI活用を前提とした見積もり・単価になっているか——AIで工数が下がるなら、その分が価格か品質に反映されるべきだ。
- AI利用時の知的財産・機密情報の取り扱い条件は何か——顧客コード・データをAIに入力する際の契約条件・統制を文書で示せるか。
- 担当エンジニアのAIスキルをどう証明するか——ベンダー内の認定制度・トレーニング実績の有無。
- AIで作ったシステムの保守・引き継ぎはどうなるか——生成されたコードの可読性・ドキュメント・属人性への手当て。
チェックの勘所:6問すべてに具体的に答えられるベンダーはまだ少数だ。だからこそ、この質問群は価格表に出ない実力差を可視化する最短の手段になる。回答を比較表にして残せば、選定の説明責任も果たせる。
発注側が数字を読み違えないための注意点
「コードの95%超」「約10倍」といった数字は、調達・発注側にとって強い印象を持つ。しかし、見積もりや契約条件にそのまま転用してはいけない。対象工程、対象言語、既存資産の状態、テスト自動化の有無、レビュー体制によって、AI開発の効果は大きく変わる。
発注側が見るべきなのは、ベンダーがAIを使うかどうかではなく、AIを使った場合の成果物責任、レビュー工程、セキュリティ検査、著作権・ライセンス確認、保守時の説明責任をどう担保するかである。数字の大きさではなく、開発プロセスの透明性を評価項目に入れるべきだ。
よくある質問(FAQ)
Q. 「コードの95%超をClaudeが生成」は信じてよい数字か? A. DXCが自社利用データから推定した自社公表値であり、第三者による検証はされていない。測定条件も非公表のため、他社案件にそのまま当てはめるべきではない。ただし「AIがコードの大半を書く開発体制」が大手SIerの公式方針になったという事実自体は重く、発注側の選定基準を更新する根拠としては十分だ。
Q. 日本の中堅企業の発注にも影響があるのか? A. ある。グローバル大手の動きは国内SIer・開発会社の体制と価格設定に波及する。同日には国内でもNECとAnthropicが金融8社との協業を発表しており、国内の供給側もAI前提へ動いている。1〜2年スパンで見れば、AI活用の有無による見積もり差は中堅向け案件でも顕在化する。
Q. ベンダーがAIで開発すると、品質やセキュリティは大丈夫なのか? A. AI生成コード固有のリスク(脆弱性の混入・ライセンス問題・属人化したプロンプト依存)は実在する。だからこそ選定時に品質担保プロセスと統制を確認する必要がある。「AIを使うか」ではなく「AIをどう統制して使うか」が評価軸だ。
Q. 自社の内製開発チームにも同じ波は来るか? A. 来る。SIerの再編は内製チームの生産性基準も引き上げる。内製・外注を問わず、AIコーディングの導入設計(ツール選定・統制・教育)は2026年の開発組織共通の課題である。
社内導入判断に落とすための確認観点
AI関連の発表は、機能名やベンダー名だけで判断すると失敗しやすい。自社で見るべきなのは、利用対象業務、入力してよいデータ、権限管理、ログ取得、費用上限、モデル変更時の再評価、成果測定の方法である。特にエージェントや外部ツール連携を伴う場合は、AIがどのシステムに接続し、どの権限で何を実行できるかを図にしてから判断する必要がある。
導入の可否は「使えるか」ではなく「統制しながら使い続けられるか」で決まる。PoCでは動いても、本番では監査・費用・障害時対応・利用部門教育が必要になる。記事内の発表を自社に適用する場合は、まず1業務に絞り、成功条件と停止条件を明文化する。
GXOへ相談する前に整理しておくと早い情報
相談前には、対象業務、現在の作業時間、利用予定データ、既存システム、禁止したい操作、想定利用者数、月額予算、社内規程の有無を整理する。AI導入はモデル選定から始めるより、業務とデータの整理から始めた方が手戻りが少ない。
90日で本番判断へ進めるロードマップ
最初の30日は、対象業務とガバナンスの整理に使う。AIで置き換えたい作業、AIに渡してよいデータ、利用者、承認者、ログの保管先、費用上限を決める。ここで曖昧なままPoCを始めると、動くものはできても本番承認で止まる。
31日目から60日目は、小さな業務でPoCを行う。評価指標は「便利だったか」ではなく、処理時間、エラー率、再作業率、問い合わせ件数、判断品質など、業務KPIに結びつくものにする。AIの回答だけでなく、人が確認・修正する工程まで含めて測る。
61日目から90日目は、本番化可否を判断する。モデル・調達経路・権限・監査・費用・障害時の手順を揃え、継続運用できる形にする。ここで本番化しない判断になった場合も、入力データや業務プロセスの課題を記録しておくと、次のAI導入の成功率が上がる。
よくある失敗パターン
第一の失敗は、ベンダー発表をそのまま自社の効果見込みに置き換えることだ。発表資料の数値は、特定条件・特定環境・特定業務での値である。自社の業務量、データ品質、利用者の習熟度、承認フローが違えば効果も変わる。
第二の失敗は、PoCの成功条件を「動いたかどうか」に置くことだ。本番化に必要なのは、精度、時間削減、レビュー負荷、費用、ログ、権限、障害時対応、利用者教育まで含めた判断である。動くデモは作れても、業務に入れるための条件が揃わなければ価値は出ない。
第三の失敗は、AI利用規程を導入後に作ることだ。現場が先に使い始めると、入力禁止データ、外部送信、モデル選定、ログ確認、費用上限が後追いになる。AIは導入スピードが速いからこそ、最低限のルールを先に決める必要がある。
成果物として残すべきもの
AI導入の検討では、ユースケース定義書、データ分類表、権限設計、評価指標、費用試算、停止条件、運用責任者を成果物として残す。特に停止条件は重要である。誤回答率、コスト超過、ログ欠落、権限逸脱など、どの条件で利用を止めるかを先に決めておけば、本番後の混乱を抑えられる。
判断表:読むだけで終わらせないための整理
| 確認項目 | 見るべきポイント | NGサイン |
|---|---|---|
| 対象範囲 | どの部門・システム・データ・端末が関係するか | 「たぶん関係ない」で止まる |
| 責任者 | 判断者・作業者・承認者が分かれているか | ベンダー任せ、部門任せになっている |
| 期限 | いつまでに何を終えるか | 次回定例、落ち着いたら、など曖昧 |
| 証跡 | 判断根拠と作業結果を残せるか | 口頭確認だけで記録がない |
| 次の一手 | 今回の対応を仕組みに変えるか | 単発対応で終わる |
この表を埋めると、記事の内容を「読んだ情報」から「社内で動かすタスク」に変えられる。特に重要なのはNGサインである。NGサインが1つでも出る場合、問題は個別ニュースではなく、社内の判断プロセスにある。
公開情報は日々更新されるため、記事本文の数値や期限をそのまま固定値として扱うのではなく、一次情報の最新版、社内の対象有無、実施記録をセットで確認する。これにより、速報記事を一過性の話題で終わらせず、監査・稟議・改善計画に使える材料へ変換できる。
いつGXOに相談すべきか
- システム開発・AI開発の相見積もりで、ベンダーのAI活用体制を評価する質問項目と比較の物差しがほしい
- 既存ベンダーの見積もりがAI前提の市場水準に照らして妥当か、第三者の目で確かめたい
- 自社開発・内製チームにAIコーディングを統制込みで導入したい
GXOは、AI開発・導入支援でAI前提の開発体制構築を、AIアセスメントでベンダー提案・見積もりの中立評価を支援している。AI活用を語れる開発パートナーの選び方はAI開発会社の選定チェック連載も参考にしてほしい。→ AI開発のベンダー選定・体制構築の相談はこちら
関連記事
- NEC×Anthropic、三井住友FGなど金融8社とAI実装協業へ
- ベンダー選定チェック⑨:AI開発会社の見極め方
- Claude Fable 5(Mythosクラス)GAでAI開発コストの前提が変わる
- SIer・オフショア・内製ハイブリッドの使い分け
参考資料
本記事は2026年6月12日時点の公開情報をもとに作成。「コードの95%超をClaudeが生成」「開発速度約10倍」はDXCが自社利用データから推定した自社公表値であり、第三者検証された数値ではない。提携の詳細・展開時期は今後更新される可能性があるため、一次情報の最新版を必ず確認すること。
そのベンダー、「AIで開発する体制」を説明できますか?
AI前提のSIer再編で、開発の見積もり・納期・品質の前提が大きく割れ始めています。GXOはAI活用体制を含むベンダー提案の中立評価から、AI前提の開発・内製化支援までを一気通貫で提供します。相見積もりの前にご相談ください。
※ 営業電話はしません | オンライン対応可 | 特定ベンダーに依存しない中立評価