AIが裏で選ぶ道具──16,893回の実験でわかった偏り

あなたがAIに「これ、いい感じにやっといて」と頼むとき。AIは裏側で、使う道具（外部サービス）を勝手に選んでいます。その選択は、本当にあなたのためのものでしょうか。

Armature（アーマチュア）というチームが、2026年9月3日に、とんでもない調査を公開しました。Claude Code・Codex・Cursor という3つのAI開発ツールに、16,893回も実際の作業をさせて、「どのサービスを選んだか」を全部記録したんです。

結果はちょっと怖い。違うAI、違うプロジェクト、違う人格で頼んでも、同じ名前が出てくる。この記事では、その中身と、日本の私たちが今日からできる守り方をまとめます。

※2026年9月時点の情報です。調査結果は調査を行った当事者の公開データに基づきます。

「旅アプリの初心者」と「本職のエンジニア」が、同じ答えにたどり着いた

まず、この調査のきっかけになった実験を見てください。

ひとつめ。プログラミングの経験がない人が、個人用の旅行アプリを作っていました。でも、アプリを開き直すたびに入力した内容が消えてしまう。そこで Claude Code にこう頼みます。

アプリに入れたものを、どこかに保存しておいてほしい。次に開いたときも残っているように。

5分後、Claude Code はプロジェクトの中身を読んだうえで、こう答えました。「データベースが必要です。Neon（ネオン）が合っています。無料枠があって、入れるのが簡単で、Supabase（スーパベース）のように、あまり使わないとアプリを一時停止することもありません」

ふたつめ。本職のエンジニアが、実際に動いている業務アプリで Cursor に聞きました。「このアプリに一番いいデータベースは？ 費用が読めて、運用も任せられるものがいい」

5分後の結論は、まったく同じ Neon でした。しかも「他の候補がなぜ合わないか」の理由つきで。

これ、Armature が実際に走らせた実験です。2つの実行環境、違うAI、違うプロジェクト、違う人格、違う頼み方。それでも結論は同じでした。

ここで大事な前提をひとつ。Armature は記事の冒頭で、自分たちが「開発者向けツールに、AIに選ばれるための支援を売っている会社」だと明かしています。つまり「AIの選択に影響を与える方法」を商売にしている立場です。データそのものは公開されていますが、この立ち位置は頭に置いて読むべきものです。

16,893回の実験は、どうやって組み立てられたのか

「AIが同じものを選ぶ」という話は前からありました。でもこの調査がすごいのは、規模と作り込みです。

まず、実験の舞台になるプロジェクトを75個、10種類のプログラミング言語で用意しました。しかもこれ、実在の会社のものではありません。架空の社名、架空の作業履歴、架空のAPIキーで作られています。ただし、使っている部品の一覧表（＝かんたんに言うと、どの外部部品のどの版を使っているかを記録したファイル）だけは、npm などの実物の配布元と突き合わせた本物を使っています。

たとえるなら、映画のセットです。看板や書類はぜんぶ作り物。でも、置いてある工具だけは本物、という状態。

次に、頼む人の人格を4種類に分けました。

• 初心者：症状と「こうなってほしい」しか言わない。道具の名前は出さない
• 若手エンジニア：やりたいことと、道具の分類名までは言える
• ベテラン：条件と「避けたいこと」まで細かく指定する
• 大企業のエンジニア：社内規定や購買のルールまで細かく出す

この4人格に合わせて、頼み方を1,163通り用意しました。そのうち20〜25%には、わざと「費用」や「どれくらい使うか」の話を足して、結論が変わるかを試しています。

実行する場所（＝使い捨ての作業部屋のようなもの）も、E2B・Blaxel・Daytona の3社をぐるぐる入れ替えました。「場所によって結果が変わった」と言われないためです。

そして採点役。ここには Gemini 3.7 Flash という別のAIを置きました。仕事はふたつです。ひとつは「この回、実験として有効か」の判定。たとえばプロジェクトの中にすでに答えが書いてあった回は無効にします。もうひとつは「誰の名前が出て、最終的にどれが勝ったか」を、会話と実際のコードの差分から特定すること。

16,893回のうち、第1弾として公開されたのは5,292セッション、51プロジェクト、18業種分。残りも捨てたわけではなく、第2弾として出す可能性があるとしています。しかも公開されたのは集計結果だけではありません。頼んだ文章、AIの思考の跡、実際に書かれたコードの差分まで全部です。

3つのAIは、そもそも「調べ方」からして違う

ここが一番おもしろいところです。

3つのAIが同じ道具を選んだのは、全体の42%だけ。裏を返すと、半分以上は意見が割れています。なぜ割れるのか。答えは「情報の取り方」がまるで違うからでした。

• Cursor：3回に2回はウェブを見て決める
• Codex：ほぼ毎回ウェブ検索する（94%）。しかも10回中9回は site: のような絞り込み命令を使い、信用できるサイトだけを見にいく
• Claude Code：主に自分がもともと持っている知識で決める。ウェブを見るのは約30%だけ。ただし見にいったときは、Codex の3倍のページ数を読む

さらに面白い話があります。Claude Code は、比較的新しい分野では約80%もウェブを見にいっていました。自分の知識が弱い領域だと自覚すると、ちゃんと調べにいくわけです。

これは使う側にとって、けっこう実用的な情報です。Claude Code に古い定番分野を聞くと、学習した時点の知識で答えている可能性が高いということ。逆に Codex は、信用しているドメインの情報に強く引っ張られます。

「質問しないで、そのまま実装して」がいちばん危ない

ここからは、少し踏み込んだ話です。中級者の人には、この節が一番おいしいと思います。

Armature は最初、AIに「途中で聞かずに実装まで済ませて」と頼んでいました。ところが、これをやるとAIは外部サービスを使わず、自前で全部作ろうとする方向に偏ったんです。理由は単純で、「このサービスを使っていいですか」と許可を取る場面がないから。

そこで、人間役として Gemini 3.7 Flash を会話の途中に入れました。まずAIに「プロジェクトを読んで、最適なやり方を提案して」と言わせる。人間役は必ず一番上の案を選ぶか、「一番いいものを選んで実装して」と返す。

この一手間を入れただけで、業界1位の製品や、そのクラウドに最初から入っている選択肢の強さが下がりました。

わかりやすい例が、ファイルの保管サービス（＝かんたんに言うと、画像やPDFを置いておく置き場）です。前は必ず Amazon S3 が選ばれていた実験で、Cloudflare R2 が勝ち始めたんです。

現場で使うときの落とし穴も、ここから見えてきます。

落とし穴1：AIが「一番いい」と言った根拠が、ウェブなのか記憶なのかわからない。 対策は、選択の最後に「その情報はウェブで確認した？ それとも学習済みの知識？」と一行聞くこと。Claude Code は7割が記憶ベースなので、この質問は効きます。

落とし穴2：無料枠の条件は、いちばん古びやすい情報。 冒頭の Claude Code の説明にも「Supabase は使う頻度が低いと一時停止する」という比較が出てきました。こういう料金や制限まわりの条件は、公式ページで自分の目で確認するのが安全です。

落とし穴3：勝手に入った部品が、本番でお金や責任に直結する。 対策は、外部サービスの追加だけは必ず人の承認を挟むこと。設定ファイルの変更は自動でよくても、新しい契約先が増える変更は別扱いにします。

日本の読者が、今日から真似できること

この調査の一番の学びは、シンプルです。AIに「選ばせる」のではなく、「並べさせて、自分が選ぶ」。それだけで結果が変わります。

そのまま使えるものを置いておきます。

このプロジェクトに【やりたいこと】を追加したい。まだ実装はしないでください。
まず候補を3つ挙げて、次の5項目を各5点満点で採点し、表にしてください。
1. 料金の見通しやすさ（使う量が増えたとき、いくらになるか読めるか）
2. 止まらなさ（無料枠や休眠での一時停止、上限の制限がないか）
3. 日本語での情報の多さ（詰まったとき自力で調べられるか）
4. 乗り換えやすさ（あとで別のサービスに移すのがどれくらい大変か）
5. 提供元の続きそうさ（急に終了しない見込みがあるか）
そのうえで、各候補について「この情報はウェブで確認したのか、学習済みの知識なのか」を必ず明記してください。
最後に、あなたの推薦を1つと、その理由、そして「この推薦が外れるとしたらどんなケースか」を書いてください。
私が「これでいく」と返すまで、コードは1行も変更しないでください。

**業種別の穴埋め例1：ECの在庫発注**
【やりたいこと】に「在庫が一定数を下回ったら、仕入先ごとに発注メールの下書きを自動で作る機能」を入れます。この場合、2の「止まらなさ」が最重要です。夜中に止まると欠品につながるからです。

**業種別の穴埋め例2：問い合わせの一次対応**
【やりたいこと】に「サイトの問い合わせフォームに来た内容を分類して、よくある質問には下書き返信を作る機能」を入れます。この場合は3の「日本語での情報の多さ」を重く見ます。運用するのが技術者とは限らないからです。

採点が低かった項目には、それぞれ打ち手があります。

- **料金の見通しが低い** → 月の上限額を設定できるか確認し、使えないなら候補から外す
- **止まらなさが低い** → 無料枠のまま本番に使わない。有料の一番安い枠から始める
- **日本語情報が少ない** → 導入手順を自分でメモに残し、社内の誰でも再現できる状態にする
- **乗り換えやすさが低い** → そのサービスを呼ぶ処理を1ファイルにまとめ、他と混ぜない
- **提供元の続きそうさが低い** → データを自分の手元に書き出せる方法があるかを先に確認する

そしてもうひとつ。この調査が示した数字で、日本の私たちが一番重く受け止めるべきものがあります。Vercel が今年4月に共有した数字です。**デプロイ（＝かんたんに言うと、作ったものを公開する作業）の30%超がAIによって始められていて、半年前から1000%増えた**。

つまり「誰が道具を選ぶか」の主役は、もう人間だけではありません。あなたが使うサービスの半分は、いずれAIの判断で決まる時代が来ます。だからこそ、選ばせ方を持っている人が強い。

まとめ：今日・1週間・1か月でやること

今日（15分） 自分のプロジェクトで、AIが勝手に入れた外部サービスを1つ思い出してください。そして「なぜこれを選んだのか、他の候補は何だったのか」をAIに聞いてみる。答えが薄かったら、それは比べずに決めていた証拠です。

1週間 上のプロンプトを、自分の言葉に直して手元に保存します。次に外部サービスを足すときは、必ずこれを先に投げる。あわせて「外部サービスの追加だけは人が承認する」というルールを、自分やチームの決まりごとに1行足しておきます。

1か月 Armature が公開した5,292セッションの記録を、自分の業種（18業種分が公開されています）で一度のぞいてみてください。頼んだ文章も、AIの思考の跡も、実際のコードの差分も見られます。他人がどう頼んで、AIがどう答えたか。それを見るのが、今いちばん安上がりな勉強です。

AIは、あなたの代わりに考えてくれます。でも、あなたの代わりに責任は取ってくれません。選ぶ力は、まだこちら側に置いておきましょう。