AIを配っても「一部の人」しか変わらない。それを全社で越えたSierraの5つの教訓をClaude Codeで確かめた
AIツールは増えたのに、仕事は変わらない。使い込むのはいつも一部の人だけで、多くは一度触って、そのまま開かなくなる。どの職場でも起きていることです。
私にも覚えがあります。鳴り物入りで入れたのに、最初の週だけ触って、それきり開いていないAIツールが、私のパソコンに眠っています。試した日がいちばん盛り上がっていて、気づけば存在ごと忘れている。サボったわけでも、嫌いになったわけでもないんです。ただ、毎日の仕事に食い込む前に、熱が冷めた。それだけでした。
そんな私でも、いまは毎朝、パソコンを開くと、昨夜のうちに走らせておいた3つの作業が結果を返して並んでいます。Claude CodeとCodexを画面を分けて並行で動かすようになってから、こなせる量は体感ではっきり変わりました。ただ、この景色が周りに広がっているかといえば、そんな気配はありません。セッションを並べて回す発想には、なかなか行き着かない。かつての私がそうでした。道具を配っただけでは、チームは動かない。
その「一部の人だけ問題」を、会社まるごとで越えた実例が出てきました。「AIが効く人は限られる」という前提を、根性ではなく仕組みで崩した話です。Sierraという、AIカスタマーサービスの会社です。
率いるのは、Salesforceの共同CEOを務め、いまはOpenAIの取締役会長でもあるブレット・テイラー（Bret Taylor）。その会社が、社内向けのAIエージェント（人が細かく指示しなくても、複数の手順を自分でこなすAI）を全社員に配りました。3月からの数か月で、規模はここまで来ています。
使っている社員は600人以上（ほぼ全社）
エージェントのセッションはのべ75,000超
コード修正の申請の7割がエージェント経由
7月9日に公開された、その5つの教訓。奇しくもきっかけは、私と同じでした。エンジニアたちがClaude CodeとCodexを並行で走らせ始めたこと。遠い成功譚としてではなく、あなたの現場に置き換えて読んでいきます。
🎯 この記事の要点（2026年7月13日時点・出典はSierra公式ブログ）
① AIは“役割ごとに増やす”より、1つの窓口に束ねるほうが効いた
② 呼ばれてから動くAIは半分。先回りして下書きを置くAIが本命
③ 壁はもう“頭の良さ”ではなく、自社の事情をどう渡すか
④ 既存システムは置き換えず、AIをその上に乗せる
⑤ 追うべきは使用量ではなく、“何が変わったか”という成果
鍵は「ツールを増やすこと」ではなく、むしろ逆に「1つに束ねること」でした。ここが、いちばん意外なところです。
教訓1｜AIは“増やす”より、“1つに束ねる”
最初にSierraがやったのは、直感的な方法でした。役割ごとにAIを分けたのです。
サポート担当、データ分析担当、エンジニア担当、営業担当。人間の部署に合わせて、4体のエージェントを用意しました。分かりやすい。……のに、これがうまくいきませんでした。
理由は2つ。表面的には、社員が「どの用件を、どのAIに頼むんだっけ」を毎回覚える負担です。もっと根っこにあったのは、本当に価値のある仕事は、部署の“中”ではなく“あいだ”で起きるという事実でした。
たとえば製品を1つ世に出すとき。技術も、営業も、マーケも、法務も動きます。部署が分かれているのは、1人・1チームでは全部を担えなかったからにすぎません。AIは、その担えなかった横断を丸ごと引き受けられます。
そこでSierraは4体を1体に束ねました。1つのSlackの宛先、1つのURL、質問から完成まで途切れない1本のスレッド。どのシステムを見に行くかはエージェントが判断するので、社員は考えなくていい。
複雑さを吸収するのは技術であって、社員ではない。
これは自分ごとにすると刺さります。社内で「経理bot」「議事録bot」「問い合わせbot」と増やすほど、どれに何を頼むのか誰も覚えられなくなる。窓口は、1つでいいんです。
手はじめに、社内にあるbotやAIの窓口を一度ぜんぶ書き出してみてください。1つに寄せられないかを考えるだけで、「どれに頼むんだっけ」の迷いが消えます。増やすほど、散らかる。まず束ねる、です。
教訓2｜“呼ばれてから動く”AIは、半分しか使えない
ここまでは「1つに束ねる」話でした。次は、その1体を“いつ動かすか”の話です。
ほとんどの仕事は、一度の作業では終わりません。数日、数週間、ときに数か月かけて、状況が変わりながら進みます。
呼ばれたら現れて、会話が切れたら忘れるAIは、そこまで。Sierraのエージェントは仕事が終わるまでスレッドを持ち続けます。だから「先回り」ができる。
会議の前には準備メモが置いてある。面接のあとにはデブリーフ（振り返りメモ）の下書きができている。レビュー依頼には、要点とリスクの一覧が最初から付いてくる。
目的は、通知を増やすことではない。未完成のまま届く仕事を、減らすことだ。
正直に書いておくと、Sierra自身も「まだ完全にはできていない。多くのやり取りは、いまも人の指示から始まる」と認めています。ここは発展途上。ただ向かう先ははっきりしています。
「AIに聞けば答える」から「AIが先に下書きを置いておく」へ。この逆転が効き始めると、頼む前の“お膳立て”に使っていた時間が、まるごと浮きます。
今日ひとつ試すなら、いつもAIに“聞いて”いる作業を1つ選んで、“先に下書きまでさせる”に変えてみてください。会議の議事メモでも、メールの返信でもいい。私は翌朝の資料の下書きを夜のうちに作らせておくようにしてから、朝いちばんの30分が“ゼロから書く時間”から“直すだけの時間”に変わりました。これができると強いです。
そのまま使える指示文を1つ置いておきます。会議名だけ変えれば動きます。
明日の定例会議のアジェンダと関連資料を読んで、議事メモの下書きを先に作っておいて。決めるべき論点は先頭に箇条書きでまとめて。教訓3｜壁は、もう“頭の良さ”じゃない
下書きを先回りで置けるようになると、今度は別の壁にぶつかります。少し前まで、その壁は「モデルが十分に賢いかどうか」でした。でも、いまは違います。
いまの最前線のモデルは、たいていの業務には十分に賢い。だから壁は移りました。次の壁はコンテキスト（AIに渡す前提情報）、つまりあなたの会社にしかない事情です。自社の手順、過去の経緯、判断の背景。どれも、AIの学習データには載っていません。
1月、Sierraの2人がClaude Codeと、その頭脳にあたるAIモデルOpus 4.6を使って、社内のデータ分析エージェントを即席で組みました。MCP（Model Context Protocol。外部のツールやデータとAIをつなぐ、共通のコンセントのような仕組み）と、コマンドライン（文字で命令する操作画面）経由で、社内システムに接続します。
すると、細かい指示なしで、Slack・GitHub・ClickHouse・Salesforce・PagerDuty（チャット、開発、データ、顧客管理、障害対応。いずれもSierraの社内の道具です）を横断して顧客の問題を数分で調べられた。以前は午後をまるごと使っていた調査が、対応の“最初の一歩”に変わったのです。
ただ、全部に触れられるAIは、強力な反面リスクの塊でもあります。SierraはここをMCP Gatewayという仕組みで抑えています。37の社内システムへの接続を、この1枚の“関所”にまとめているのです。要点は、この4つ。
社員本人の権限を、そのまま引き継ぐ（その人が見られないものは、AIも見られない）
すべてのツール呼び出しで、会社のポリシーを適用する
顧客のデータは、きちんと隔離する
誰が何をしたか、監査ログを残す
使わない権限は、最初から渡さない。それだけの話で、設定もそのほうが早く終わります。
これは私も日々感じるところです。まっさらな指示で頼むより、自分のファイルや文脈を渡してから頼んだほうが、返ってくるものが一段良くなる。賢さより、“何を知らせているか”で差がつく。実感と、Sierraの主張は重なります。
1つだけ、読み方の注意を。「37システム接続」「数分で」といった数字は、あくまでSierraの自己申告です。第三者の検証ではありません。ただ、仕組みとしての筋は通っている。ここは切り分けて受け取るのが誠実だと思います。
次にAIへ頼むときは、まっさらな指示ではなく、関連するファイルや過去のやり取りを1つ添えてから頼んでみてください。返ってくるものの質が変わるのが、すぐ分かります。壁は賢さではなく、渡す情報のほうにある。この話が借り物の受け売りでないことは、記事の後半で、私自身のClaude Codeを使った実測でお見せします。
教訓4｜AIが“窓口”、いまのシステムは“裏方”
コンテキストを渡せるようになると、次はアウトプットの置き場所が問題になります。
どんな仕事も、最後は何か“アウトプット”（できあがった仕事のかたち）を生みます。エンジニアならプルリクエスト（コードの変更をチームに出す申請書のようなもの）。営業なら提案書、契約書、事例記事、スライド、評価シート。
Sierraの発想はシンプルです。このアウトプットは、AIへの入力でもあり、出力でもある。「このスライドを締めて」と頼むと、返ってくるのは“どこを直すべきか”のチャットではなく、直ったスライドそのものです。
そして大事な判断がここ。既存のシステムは、置き換えません。持ち場は、そのままにします。
GitHub はコードを持つ
Salesforce は顧客を持つ
Linear は課題を持つ
AIは、それらを上から横断する層になります。どこか1つに主権を移すのではなく、全部の上に薄くかぶせるイメージです。
置き換えようとすると、2つの問題が起きます。
数十年かけて磨かれたソフトを、一から作り直す羽目になる
会社が「AI経由で働く人」と「元ツールで働く人」に割れて、“正しいデータ”が2つになる
だから、置き換えるのではなく、上に乗せる。既存の道具は、そのまま生かすのが正解でした。
あなたの導入判断にもそのまま効きます。「今の道具を捨てて、AIに全部移す」ではなく、「今の道具はそのまま、AIをその上に乗せる」。こちらのほうが、たいてい現実的です。
ためしに、AIに“できあがったもの”について質問するのをやめて、“できあがったもの”そのものを直させてみてください。「この資料のここを詰めて」と頼み、直った資料が返ってくる。私はスライドの手直しをこの方式に変えただけで、「どこを直すべきか」を聞いてから自分で直す二度手間が消えました。これが、窓口としてのAIの使い方です。
この提案書の「導入効果」の節を、本文中の数字を根拠に具体的に書き直して。説明ではなく、直した提案書そのものを返して。教訓5｜“たくさん使った”は、成果じゃない
窓口として使い始めると、次に来るのは「で、どれだけ効いたの？」という問いです。最後は、いちばん誠実で、いちばん耳が痛い教訓です。
3月以降、のべ75,000セッション超。プルリクエストの7割がエージェント経由。数字は魅力的で、つい見出しにしたくなります。導入初期は、これを追うのが正解でもあります。まず使う習慣がつかないと、効いているかどうかも測れないからです。
でもSierraは釘を刺します。セッション数やツールを呼んだ回数は“活動量”であって“成果”ではない。
ここで効いてくるのがトークン（AIの利用量の単位）です。Sierraはこれを「トークンマックス（tokenmaxx）」と呼びます。トークンを使い倒せば、見栄えのいい利用グラフは作れてしまう。でも下流では何も良くなっていない。同じミス、同じ納期、ただAIがより多く関わっているだけ。そんな状態もありえます。
問うべきは「AIがどれだけやったか」ではなく、“それで何が変わったか”。商談が速く決まったか。顧客の問題が一発で片づいたか。誰かが、レビューを夜中までやる代わりに、夜を取り戻せたか。
Sierraも「まだうまく測れていない。数えるほうが簡単だから」と率直に認めています。その“測れるもの”と“本当に大事なもの”のギャップを次に埋める、と。
参考：Sierraが公開した“活動量”の数字
いずれもSierraの自己申告値です（出典は末尾）。それでも、規模の実感はつかめます。
エージェントの累計セッション: 75,000超（3月の初コミット以降）
使っている人数: 600人超（ほぼ全社に浸透）
エージェント経由のプルリク: 70%（活動量としては十分）
あなたの会社でも、稟議やKPIで「AIのセッション数」を成果として掲げそうになったら、いったん止める。測るべきは、時間・品質・意思決定の速さのほうです。ここ、耳が痛い人も多いはずです。私も気をつけています。
できることは1つ。いまAIの成果を「使った回数」で語っているなら、指標を1つだけ入れ替えてください。「何が速くなったか」「何が一発で決まったか」。数えにくいほうにこそ、価値があります。
【実測】この教訓、私のClaude Codeで確かめました
「賢さより文脈」。教訓3のこの話が本当かどうか、借り物のままにせず、手元のClaude Codeで確かめました。
用意したのは、架空の請求書ツール（Alpha食品）です。プロジェクトの規約を書いたCLAUDE.md（金額は3桁カンマ区切り・エラー文言は日本語・関数名は snake_case（小文字の単語をアンダーバーでつなぐ書き方）・顧客名はマスク）と、わざと規約違反を4つと税率のバグを1つ仕込んだ invoice.py を置きました。作業の段取りを書いた BRIEF.md も、同じフォルダに入れてあります。
置いた CLAUDE.md の中身は、これで全部です。社名と規約の4行をあなたの職場のルールに書き換えれば、そのまま流用できます。
# 社内ツール開発の規約（架空プロジェクト: Alpha食品 請求書ツール）
このリポジトリのコードを直すときは、必ず次の規約に従うこと。
## コーディング規約
1. 金額の表示は必ず日本円で、3桁カンマ区切りにする（例: 1,200,000円）
2. エラーメッセージ・ユーザー向け文言はすべて日本語にする
3. 関数名は snake_case（キャメルケース禁止）
4. 顧客名はログに出す前にマスクする（例: 佐藤 → 佐◯◯）
## 注意
- 税率は消費税10%。price * 1.1 で計算する渡したプロンプト（AIへの指示文）は、これだけです。
CLAUDE.md の規約をすべて読んでから、invoice.py を規約どおりに直してください。規約違反とバグを漏れなく修正し、最後に『直した箇所』を日本語の箇条書きで報告してください。Claude Codeはまず CLAUDE.md（＝コンテキスト）を読み込み、それから invoice.py に手を入れ始めました。まっさらな指示ではなく、会社のルールを先に渡した状態です。
返ってきたのは、説明ではなく直った invoice.py そのものでした。教訓4「AIが窓口、成果物が返る」の、そのままの動きです。
結果は、正直おどろきました。所要は1分32秒。仕込んだ5件（規約違反4つ＋税率バグ1つ）を全部直しただけでなく、私が頼んでいない順序のバグ（不正入力の判定が合計計算の後にあった）も自分で見つけて、計6件を直していました。
しかも、直して終わりではありません。自分で1回実行して、正しい入力（正常系）・わざと壊した入力（異常系）・マスクまで検証していました。出力はこうです。
そして地味に効いたのが、ここ。マスクの伏せ字「◯」の数を、規約の例からは固定とも可変とも読める、と気づいて、勝手に決めずに「要確認」として残したんです。先回りしつつ、判断は人に戻す。教訓2そのものでした。
変更差分をまとめさせたときも、頼んでいないのに「__pycache__（Pythonが自動生成するキャッシュ）が一緒に登録されています。普通はコミットに含めません」と指摘してきました。文脈を持つと、ここまで気が回ります。
まっさらな指示だったら、たぶん英語のまま直したでしょう。規約というコンテキストを1枚渡しただけで、成果物が会社のルールに沿った。教訓3は、私の手元でも本当にそうなりました。借り物だった5つの教訓が、1つだけ、自分のデータになった瞬間です。
おわりに｜“できる1人”に頼る時代の、静かな終わり
Sierraは自社ブログの締めくくりで、書き出しに置いた1968年の研究に話を戻します。最高の技術者は、その他の人の約10倍の生産性を出す。半世紀前に見つかったこの差に対して、これまで答えは1つしかありませんでした。「その希少な1人を、探し出す」ことです。
いま、もう1つの答えが出てきました。全員に相棒を配って、“少数の優位”を全員が持てるようにする。Sierraが社内でやってみせたのは、まさにそれでした。
冒頭で私は、セッションを並行で走らせて“こなせる量が変わった”と書きました。あれはまだ入り口です。1人の生産性が上がる話から、チーム全員の底が上がる話へ。Sierraの5つは、その移り方を教えてくれます。
そして目的は、「もっとたくさんこなす」ことではありません。判断、センス、創造、そして人との関係。人にしかできない仕事に、時間を返すことです。
順番はもう分かりました。まず束ねる。呼ばれる前に動かす。そして、使った量ではなく“何が変わったか”を見る。あなたのチームで最初に束ねる“1つの窓口”は、どの仕事にしますか。
出典（一次ソース）
Sierra公式ブログ「AI-pilling our company: lessons learned」（本記事の元記事・Neil Rahilly、2026年7月9日）
Sackman, Erikson & Grant (1968) — Sierraが引用する“10倍差”の元研究（ACM）
Claude CodeやCodexを“実務でどう使うか”を、こうして海外事例も交えて書いています。役に立ったら、スキとフォローをもらえると励みになります。