企業はとっくに「AIを使うか否か」の段階を過ぎている

Anthropicは企業向けの電子書籍《Building AI agents for the enterprise》（企業向けAIエージェント実践ガイド）を発表した。サブタイトルは「業界リーダーから学ぶベストプラクティス」。この本は、静かに進行していながらほとんど言語化されてこなかったある事実を表舞台に引き出した。

あるテクノロジーの普及率が2年で倍増し、なお加速しているとき、誰が使っているか・どれだけ使っているかは、もはや差別化要因にはならない。企業と企業の差を本当に分けるのは、別の問いだ。AIを机の上に置いた一つの道具として扱うのか、それとも会社全体を再編成する基盤能力として扱うのか。

この本はその変数を取り出し、名前を付けた。エージェント的思考の分水嶺（agentic thinking divide）だ。以下では、本書の中で最も鋭い二つの命題——なぜscope（対象範囲）がすべてを決めるのか、なぜこの優位性が複利で増えるのか——を順に解きほぐしていく。結論を丸暗記する必要はない。読み終える頃には自分で導き出せるはずだ。

「採用」と「変革」：二つの道の違いは一目瞭然

一言でまとめるなら：点在型の施策は、点在した結果しか生まない。一つひとつを見れば問題はなく、デモとしてはむしろ見栄えがすることも多い。だが共通の運命がある。永遠にパイロットの段階に留まり、会社の動き方には何の変化ももたらさないということだ。

点在型の施策が、必然的に平凡になる理由

まず主張を先に出そう。AIを孤立した道具として使う会社は、その結果が平凡になることが運命づけられている。これは姿勢の問題ではなく、構造が決めることだ。

これらのツールが食べているのは「汎用AI」であり、汎用AIが出すのは汎用の成果物だ。文法は正しく、構成も整っているが、誰が見ても「結局これは手直しが必要」だと感じるもの。問題はまさにこの「結局手直しが必要」という点にある。社員はAIが起草した文書を受け取り、それが会社の基準を理解しておらず、社内用語を使いこなせず、老練な社員の頭の中にしかなく、どんな文書にも書き起こされたことのない組織知識（institutional knowledge）を知らないことに気づく。結果、社員はさらに時間をかけて手を入れ、使えるレベルまで磨き上げなければならない。

その証拠は何か。本書には繰り返しこの現象が登場する。同じモデルを使っている二社が、まったく異なる結果を出す。差はどれだけの組織的文脈を注ぎ込んだかにある。この一文は事実上「モデル決定論」に死刑を宣告している。同じモデルがまったく異なる結果を生み出せるなら、モデルが決定変数でないことは明らかだ。決定変数はscope（対象範囲）である。AIを点在型の道具として扱えば、点在した結果しか得られない。変革として扱えば、社員の働き方・プロセスの回り方・生み出せる製品という三つを同時に組み替えることになる。

この三つこそ、本書の骨格である三本の柱だ。一本ずつ見ていこう。それぞれの背後には実在する一社が立っている。

L'Oréal：全員のスタートラインを前に押し出す

冒頭のあの営業の話に戻ろう。あの数秒間を成立させたのは、モデルが賢くなったからではない。モデルがこの会社の実データの流れ——CRM、会議録音、見込み客調査——に接続されていたからだ。会社が変わり、データが変われば、同じモデルでもこのブリーフィングは作れない。

この現象は営業だけの話ではない。財務はデータウェアハウスに接続すれば決算レポートを出し、法務は自社のリスクフレームワークに沿って契約を審査し逸脱条項を洗い出し、マーケティングはブランドガイドラインに沿ってキャンペーン案の初稿を起草する。パターンは一貫している。価値の大きさは、組み込んだ組織知識の量に比例する。

L'Oréal（ロレアル）はこの法則を数値化した。同社の状況を想像してほしい。製品は150以上の国で販売され、データは各所のパイプラインに散在している。ある社員がどこかの市場のある製品ラインの最近の売れ行きを知りたいと思えば、要望を出し、データ専門家にカスタムクエリを作ってもらうのを待ち、その専門家が本当に知りたいことを正しく理解してくれることを祈るしかなかった。会社全体のデータ活用力が、このボトルネックで詰まっていたのだ。

同社の解決策は、Claudeをベースにした社内AIプラットフォームの構築だった。マルチエージェントシステムが、社員が普段の言葉で投げた質問を、正しいデータソースと15以上の専門agentに自動でルーティングし、図表付きの回答にまとめ上げる。

ここで注目すべきは「より強力なモデルに乗り換えた」ことではない。90種類の案に対して1つの99.9%——大量の案を試してどれもうまくいかず、うまくいった唯一の案が、15の専門agentと正しいデータソースを的確にオーケストレーションしたその案だったという点だ。オーケストレーションと文脈こそが、90%から99.9%へのその溝を埋めた材料である。このプラットフォームを率いるThomas Menard氏（L'Oréal エージェントプラットフォーム&LAB責任者）はこう語る。「LLM-as-a-judgeのような自動評価能力によって、Claudeモデルの優位性はすでに何度も証明されている」。

Lyft：「数ヶ月」を「数分」に圧縮する

この柱が語るのはもう一つの光景だ。誰か一人が速くなるのではなく、パイプライン全体が速くなる。しかも直感に反する法則がある。プロセスが複雑で情報密度が高いほど、得られる恩恵は大きくなる。

理由はやはり同じだ。プロセス自動化の価値は、その背後にある文脈だけで決まる。基準、コンプライアンス要件、組織知識をシステムに組み込めば、処理時間は数ヶ月から数分へと縮まり、しかも品質は落ちない。成功とはどんな姿か。臨床文書作成者は、数週間かけてレポートをつなぎ合わせる仕事から、大半の稼働時間をレビューと仕上げに使う仕事へと変わる。コンプライアンス担当者は、数日かけて規制当局への提出書類を作る仕事から、数分で初稿を生成する仕事へと変わる。チーム全体が、稼働時間の80%を文書作成に使う状態から、80%を判断に使う状態へと変わる。

Lyftはこの柱の何よりの証拠だ。もし夜遅くに配車サービスでトラブルに遭った経験があれば、あのイライラを覚えているかもしれない。行程に問題が起き、カスタマーサポートに電話をかけても30〜40分待たされ、電話に出たオペレーターは同時に3、4人を相手にしていて、返ってくる答えはコピペのテンプレート文ばかり。これがまさにLyftのかつての状況だった。6大陸、何千もの都市にまたがるサービスで、サポート体制は限界に押し上げられ、オペレーター自身の燃え尽き感も急上昇していた。

LyftがClaudeを選んだのは、しっかり比較検討した上でのことだった。一つはパフォーマンスそのもの、もう一つはブランドの声との相性。ドライバー向けサポートから始め、乗客サポート、請求紛争へと拡張した。今の現場はこうだ。Claudeが顧客の名前を呼んで挨拶し、具体的な状況を調査し、数秒で解決する。人の判断が本当に必要な場合にのみ、チケットと自動生成された会話の要約を添えて、有人サポートに回す。

ここで注目したい因果関係がある。解決時間が87%短縮したのは、Claudeがオペレーターよりタイピングが速いからではない。Lyftの業務フロー全体に組み込まれ、調査でき、判断でき、人に引き継ぐべきタイミングで要約を添えて引き継げるようになったからだ。これは組み込みの深さに対する見返りであり、モデルの速さに対する見返りではない。

浮いたコストは数百万ドル規模にのぼるが、Lyftはそれを懐に入れず、サポートチームと新プロジェクトに再投資した。その一つがLyft Silverで、高齢の乗客専用のパーソナルサポートだ。AIが人を機械的な労働から解放し、浮いたコストが、そもそも存在しえなかった、より血の通った新サービスに姿を変えたのだ。

Rakuten：顧客に、以前はできなかったことをさせる

前の二本の柱は社内向けだったが、この柱は社外向けだ。AIはコストを削減するだけでなく、そもそも作れなかった製品を作れるようにする。

本書はある共通パターンを指摘する。フロンティアAIモデル＋独自データ＋既存の信頼関係＋深い専門知識。AIはあくまで実現手段にすぎず、本当の参入障壁はそれを取り巻くすべてから生まれる。だから製品レイヤーの機会は「コスト削減」にとどまらない。新しい製品能力によって純増収益と複利で増える競争優位を生み出すことだ。先に動いた者は連携、データのフライホイール、顧客の習慣を築き上げ、後発組が追いつくのを難しくする。

この柱を最も完全な形で体現しているのがRakuten（楽天）だ。同社は70以上の事業を運営し、全社を挙げて「AI化（AI-nization）」戦略を推進している。同社は早い段階でこう見抜いていた。agentが本当に働くには、持続的な計算資源、記憶、ストレージが要る。そこでエンジニアはまずゼロから基盤を作り始めた。この判断は当時としては正しかったが、代償もあった。本来なら差別化のためのイノベーションに投じられるはずのトップ人材が、丸ごと基盤づくりに費やされてしまったのだ。

転機となったのはClaude Managed Agents（Claudeプラットフォームが提供する、あらかじめ構築済みで設定可能なagent実行フレームワーク）の採用だった。「実行層」という地味で骨の折れる仕事をまるごと外に出し、自社のエンジニア人材を本当のagentic体験の磨き込みに集中させられるようになった。効果はまるで堰を切ったようだった。わずか1週間で、エンジニアリング・製品・営業・マーケティング・財務をカバーする専門agentがデプロイされ、Slack、Microsoft Teams、自社のカンバンシステムに直結し、数時間にわたる長時間タスクをこなすようになった。しかもagentの記憶は複利で増える。過去に犯したミスを覚えているので、二度と同じ轍を踏まない。

だがRakutenで最も印象に残るのは数字ではなく、ある一枚の光景だ。社内では領域を横断して貢献するスーパーユーザーを「Galileo（ガリレオ）」と呼んでいる。その一人はプロダクトマネージャーで、エンジニアではない。彼はたった一人で、複数のパブリッククラウド上にFinOps（財務運用）のパイプラインを構築し、バックグラウンドで静かに動く監視agentまで自分で設計した。以前ならプロダクトマネージャーがこんなことを考えることすら思いもよらず、エンジニアリングチームに列をなして頼み込むしかなかっただろう。これこそRakutenが示した構造的な結論だ。agentはあなたの未来の同僚でも、職を奪う競争相手でもない。会社があらゆるものの構築を加速するためのインフラなのだ。

この優位性は線形ではなく複利で増える

ここまでで最初の二つの論点はすでに成立している。点在型の施策は平凡に終わり、変革は組織の文脈に支えられる。だがこれだけでは足りない。もしこの優位性が「一度だけ他社より一歩リードする」だけのものなら、いずれ追いつかれる。本書が最も鋭く突く命題は三層目にある。この優位性は雪だるま式に増え、先に動いた者と後発組の距離はどんどん開いていく。

複利はどこから生まれるのか。本書は「精度がどう複利で増えるか」という、かなり具体的なメカニズムを示している。よくあるやり方は、専門家に毎回同じ基準からAIの成果物をレビューさせるというものだ。専門家は疲弊し、AIはずっとその場に留まったままだ。正しいやり方は、人間の専門性から得たフィードバックをAIのナレッジベースに戻す仕組みを作ること。専門家が一度レビューするたびに、以降のすべてのプロセスがより良くなる。つまりAIの能力曲線は右肩上がりであり、横ばいではないということだ。

「道具」と「インフラ」を区別することが、複利を理解する鍵だ。道具は使い終えたら元に戻すもので、価値は固定されている。インフラはその上にどんどん建て増していくもので、積み上げるほど価値が上がっていく。点在型の施策は道具であり、変革はインフラを敷いていくことだ。だからこそ前者は線形で、後者は複利になる。

このメカニズムを突き詰めると、結論はまっすぐだ。最も早く始めた組織が、最大の優位性を蓄積する。毎月積み上がる承認記録、専門家のフィードバック、修正事例のすべてが、翌月の成果物をより速く、より正確にしていくからだ。1年遅れて始めるということは、1年分遅れるということではない。「1年分の複利」分だけ遅れるということだ。競合はその1年の間、毎月着実に強くなっていくのに対し、あなたはゼロからのスタートになる。

プラグインが組織知識を組織インフラに変える

ここまでで論理の連鎖はすでに閉じている。点在は平凡→変革は文脈に支えられる→文脈は複利で増える→だから先に動いた者が勝つ。だがこの連鎖には暗黙の前提がある。これまでの事例を振り返ると、L'Oréalの15agentオーケストレーション層、Lyftのサポートシステム、RakutenのManaged Agents、さらに本書で触れられているNovo Nordisk（NovoScribeが臨床研究文書を10週間超から10分に圧縮）、RBC（agentソリューションが2200人のアドバイザーをサポートし、6890億ドルの資産を管理）——どの会社も、Claudeに文脈を与えるためだけに、自前でカスタムプラットフォームを構築している。

見返りは大きいが、参入障壁も高い。エンジニアリングリソース、時間、技術専門知識がいずれも必要になる。このゲームのスタートラインは「自前でプラットフォームを構築できるエンジニアリングチームを持っていること」に設定されてしまっている。大多数のナレッジワーカーはこの門の外に締め出されている。

Claude Coworkはこの方程式を変えた。非エンジニアでも、企業がAPI上で自前構築するのと同じagent能力を、一切のカスタム開発なしに手に入れられるようにする。タスクを渡せば、返ってくるのはアドバイスの一文でも、アウトラインでもなく、本当にやり終えたもの——Wordの文書、Excelのモデル、スライド一式、分析レポートだ。

その裏にある仕組みがplugins（プラグイン）だ。skills（スキル）、文脈、コネクタを一つにパッケージして、Claudeにロール専属の専門性を与える。かつては老練な社員の頭の中に鍵をかけて眠り、その人が去れば消えてしまっていた組織知識が、今やプラグインとしてパッケージ化され、複製・共有・蓄積できるようになった。つまり「個人の学習を組織の学習に変える」ことが仕組み化されたのだ。Anthropicはすでに11個のプラグインをオープンソース化しており、生産性、営業、財務、データ、法務、マーケティング、カスタマーサポート、プロダクトマネジメント、企業内検索、生物学研究、そしてプラグイン管理そのものをカバーしている。

これを企業内で実際に運用可能にするために、本書は企業レベルの四要素を挙げている。ガバナンス管理（組織専属のプラグインマーケットプレイスにより、ガバナンスを受け身の「後から止める」から能動的な「事前にキュレーションして配布する」へ変え、シャドーAIの野放図な拡散を断つ）。安全設計（タスクはローカルで実行され、何もクラウドにアップロードして処理しない。「企業AIに対する最も一般的な反対意見」が出てくる前に、それを解決してしまう）。監査可能性（OpenTelemetryと互換性があり、AIがいつ、誰の代わりに、何をしたかを正確に把握できる）。統合と継続性（既存のCRMや文書システムの中で動き、CoworkとExcel、PowerPointの間を行き来しても文脈が失われない）。

四つの原則 + 三段階タイムライン、全文収録

ここまで他社の話をたくさんしてきたが、最後は自分ごとに落とし込む番だ。本書が示す実践方法は二つだけ。四つの原則——どれも、よくある衝動に逆らうものだ——と、原則をカレンダーに落とし込んだ6ヶ月のタイムライン。この二つこそ本書の中で最も価値ある、実行可能な部分であり、以下に日本語訳の全文を収録する。そのまま持ち帰って実践できる。

① 規模ではなく、具体性から始める

最初からあなたの基準、あなたのツール、あなたの組織固有の文脈をClaudeに与えること。最初のやり取りで汎用の成果物しか受け取れなかった社員は、めったにそのツールに二度目のチャンスを与えない。本ガイドに登場する組織が成功したのは、Claudeにその会社の事業を本当に理解している人物が書いたかのような成果物を出せるだけの文脈を与えたからだ。

② 測定可能なゴールラインのあるパイロットを選ぶ

三本の柱にはそれぞれ異なる成功指標がある。社員の生産性向上は採用率と時間削減で測る。プロセスの高速化はサイクルタイムの短縮と品質スコアで測る。製品の変革は収益への影響と市場投入スピードで測る。パイロットを始める前に成功基準を明確に定義しておけば、結果が曖昧になることはない。

③ 初日から再利用を前提にプラグインを作る

誘惑は常に、ある一つのチームのために手早い解決策を作り、再利用は後で考えようというものだ。その誘惑には抗うこと。あるチームのために作ったプラグインは、組織全体が恩恵を受けられるものであるべきだ。部族的な知識を一度コード化すれば、そのプラグインをインストールするすべてのチームがすぐに恩恵を受けられる。プラグインを共有する限界コストはゼロなのに対し、限界価値は計り知れない。

④ ガバナンス層を絶対に軽視しない

管理コントロール、監査可能性、組織専属のマーケットプレイスは、大規模展開の前提条件であり、採用が軌道に乗ってから後付けする機能ではない。初期にガバナンスを飛ばした組織は、抜け駆けで浮かせた時間よりも、承認外の利用を後始末する時間の方が長くかかる。

• Start with specificity, not scale. Give Claude your standards, your tools, your institutional context from the beginning. Employees who receive generic output from a first interaction rarely give the tool a second chance. The organizations in this guide succeeded because they gave Claude enough context to produce output that felt like it came from someone who understood the business.

• Choose pilots with a measurable finish line. Each of the three pillars has different success metrics. Smarter employees might be measured by adoption rates and time savings. Faster processes might be measured by cycle time compression and quality scores. Transformative products might be measured by revenue impact and speed to market. Define your success criteria upfront, before the pilot starts, so the results are unambiguous.

• Build plugins for reuse from the beginning. The temptation is to build a quick solution for one team and worry about reuse later. Resist that temptation. Plugins built for one team should benefit the entire organization. When you encode tribal knowledge once, every team that installs the plugin gets the benefit immediately. The marginal cost of sharing a plugin is zero, while the marginal value is enormous.

• Never underestimate the governance layer. Admin controls, auditability, and organization-specific marketplaces are prerequisites for broad rollout, not features you add after adoption takes off. The organizations that skip governance early spend more time cleaning up unsanctioned usage than they saved by moving fast.

第1段階 · 最初の数週間：評価基準と成功基準を定める

最初の数週間は一つのことだけに集中する。評価と成功基準だ。痛点が明確で業務フローが測定可能なチームを2〜3つ見つける。オープンソースのリポジトリから該当するプラグインをインストールするか、自分たちのチームの基準とプロセスを組み込んだカスタムプラグインを構築する。誰かが使い始める前に、「成功とはどんな姿か」を定義しておく。

例えば、営業チームなら「通話準備時間を50%削減」でもいい。法務チームなら「契約審査のターンアラウンドを5日から1日に圧縮」でもいい。文書チームなら「初稿の品質が最終承認版の80%に達する」でもいい。成功基準がどれだけ具体的かが重要だ。「生産性を向上させる」のような曖昧な目標は、簡単に否定できる曖昧な結果しか生まない。

第2段階 · 2〜3ヶ月目：チャンピオンパイロットを立ち上げる

2、3ヶ月目はチャンピオンパイロットの期間だ。2〜3のチームが、設定済みのプラグインを備えたClaude Coworkを、サンドボックスの実験ではなく実際の本番業務フローで使う。採用率を毎週測定する。定量指標と並行して定性的なフィードバックも集める。社員が想定外の価値を発見する瞬間は、時間削減の計算よりも多くの情報を含んでいることが多いからだ。

この段階の目標は完璧さではなく、価値の証明と、大規模展開の前にまだ何を変える必要があるかを明確にすることだ。

第3段階 · 4〜6ヶ月目：影響を規模化する

成功した概念実証を手にしたら、4〜6ヶ月目は規模化とガバナンスに移る。管理者向けマーケットプレイスの管理機能をデプロイし、プラグインのレビューと承認のワークフローを確立し、パイロット期間で磨き上げたプラグインと設定をより多くのチームに展開していく。

新たにオンボードされる各チームは、すでにコード化された組織知識の恩恵をそのまま受けられる。だから第2波の展開は第1波より速く進み、第3波はさらに速くなる。これこそが複利のダイナミクスが実際に働いている姿だ。文脈、設定、ガバナンスへの投資の一つひとつが、次のデプロイをより安く、より効果的にしていく。

Phase 1: Setting evaluation and success criteria

For the first several weeks, focus exclusively on your evaluation and success criteria. Identify two to three teams with clear pain points and measurable workflows. Install the relevant plugins from the open-source repository or build custom plugins that encode your team's specific standards and processes. Define what success looks like before anyone starts using the tool.

For a sales team, for example, that might be call prep time reduced by 50 percent. For a legal team, it might be a contract review turnaround cut from five days to one. For a documentation team, it might be first-draft quality reaching 80 percent of the final approved version. The specificity of the success criteria matters: vague goals like "improve productivity" produce vague results that are easy to dismiss.

Phase 2: Launching a champion pilot

The second and third months of the initiative are the champion pilot. Two to three teams use Claude Cowork with their configured plugins in production workflows, not sandboxed experiments. Measure adoption weekly. Collect qualitative feedback alongside quantitative metrics, because the moments when employees discover unexpected value are often more informative than time-saved calculations.

The goal of this pilot phase is not perfection but proof of value and a clear understanding of what needs to change before broader rollout. Getting started with Claude Cowork in the help center provides practical guidance for configuring access and managing this initial deployment.

Phase 3: Scaling impact

Successful proof of concept in hand, months four through six shift to scaling and governance. It's time to deploy the admin marketplace controls, establish plugin review and approval workflows, and begin the rollout to additional teams using the plugins and configurations refined during the pilot.

Each team that comes online benefits from the institutional knowledge already encoded, which means the second wave of adoption moves faster than the first. The third wave moves faster still. This is the compounding dynamic in action: every investment in context, configuration, and governance makes the next deployment cheaper and more effective.

「第2波は第1波より速く、第3波はさらに速い」というこの一文こそ、先に述べた複利のメカニズムがカレンダーの上に現れた姿だ。モデルが良くなったからではなく、それまでに積み上げた文脈、設定、専門家のフィードバックのすべてが、あなたの代わりに加速してくれているからだ。

必要なのは完璧な計画ではなく、具体的な出発点だ

私たちはある営業の、電話が鳴る前の数秒間から話を始めた。今なら、その数秒間に隠されていたのが、節約できた数時間だけではないと、大体見えてきたはずだ。

論理の連鎖を一度まとめよう。モデルは決定的な変数ではない。証拠は、同じモデルが会社ごとにまったく異なる結果を出すという事実だ。決定的な変数はscope、AIを点在した道具として扱うか、変革の土台として扱うかだ。点在型の施策は必然的に平凡になる。それが食べているのは汎用の成果物であり、汎用の成果物は永遠に「結局手直しが必要」だからだ。変革を支えるのは組織の文脈をシステムに組み込むことであり、三本の柱の事例数字（L'Oréalの99.9%、Lyftの解決時間87%短縮、Rakutenの重大エラー97%削減）が繰り返し証明しているのは、差を分けるのは組み込みの深さと文脈の厚みであって、モデルそのものではないということだ。そしてこの優位性は複利で増える。専門家のフィードバックがナレッジベースに戻り、agentの記憶が積み重なり、プラグインが組織知識を共有可能なインフラに変える。だから先に動いた者と後発組の距離は開き続ける。

本書は、最もよくあり、かつ最も致命的なミスを指摘している。戦略が完璧に固まるまで最初の一歩を踏み出さないこと。成功した組織はまさにその逆だ。ごく狭い切り口から入り、素早く学び、そして確信を持って拡張していく。必要なのは完璧な計画ではなく、たった三つのものだけだ。具体的な出発点、定量化できる成功基準、そしてこれから実際に起きることから学び続ける意志。

まず基盤のメカニズムをはっきりさせよう。AIを実際に使えるものにする鍵は、自社の文脈を注ぎ込み、さらに専門家のチェックによるフィードバックをシステムに還流させることだ。そうすればAIは毎回ゼロからではなく、使うほど精度が上がっていき、複利（利子が利子を生むように、使うほど価値が増すこと）が生まれる。

行動に落とし込むと、四つの原則になる。どれもよくある衝動に逆らうものだ。

• 規模でなく具体性から入る：最初から基準・ツール・社内用語を与える。汎用の成果物がそのまま使えると期待してはいけない。
• まず定量化できるゴールラインを設定する：「通話準備を半分に短縮」のように。「生産性向上」のような曖昧な目標は避ける。
• プラグインは初日から再利用前提で作る：プラグイン（チームのツール・プロセス・資料を一つにまとめ、すぐ使えるパッケージにしたもの）は一つのチームのために間に合わせで作らない。共有の限界コストはほぼゼロだ。
• ガバナンスの防護柵は前もって敷く：誰が何を使えるか、記録を残すかどうか。問題が起きてから補うのではなく、後から補うコストは抜け駆けで浮いた分より大きい。

原則を手にしたら、ガイドはさらに6ヶ月のタイムラインを示し、それをカレンダーに落とし込んでいる。

四つの原則と三段階は、ガイドが日英対照の全文として収録しており、本文でそのまま持ち帰って実践できる。

「どれだけ速いか」は普通の人には実感が湧かない。同じ具体的な作業に置き換えて、それぞれどれくらいの時間がかかるかを見てみよう。（もう一つ避けて通れないハードルがある。金融や医療のような業種では、顧客データは会社の「信頼境界」——顧客がデータ処理を任せてもよいと思う範囲——を出てはいけない。そうでなければどれだけ強力な製品でもローンチできない。）