Claude Fable 5発表から日本企業の事例まで Code with Claude 2026東京レポート｜初心者向け徹底解説 【中編・企業事例】
楽天は開発期間79%短縮、メルカリは成果90%増
日本企業のAIエージェント活用最前線
※この記事は「Code with Claude 2026東京 完全レポート」（全３回）の【中編】です。前編では新モデルClaude Fable 5と新機能を、【後編】では開発実践のノウハウを扱います。章番号はシリーズ全体で通しになっています。
【前編】では、Anthropicの最新モデルという「賢い頭脳」と、それを安全に動かす「体」や「道具」がすべて揃ったことを解説しました。では、その強力な道具を手にした企業は、現実のビジネスでどのような結果を出しているのでしょうか？
※Claude Fable 5は2026年6月13日、米国政府の指令により公開停止になりました。この記事は公開停止前に作成しています。
この記事を読むと、次のことが分かります。
楽天・メルカリ・みずほ・NRI という日本を代表する企業が、AIエージェントを実業務に投入して得た「開発期間79%短縮」「成果90%増」といった生々しい成果の数字が分かる。
「ベンチマークの点数」と「自社業務での実力」がなぜ食い違うのか、そしてそのギャップをどう埋めればよいのかが判断できる。
数千万人のユーザーにAI機能を届けるデザインツール「Canva」（キャンバ）が学んだ、品質とコストの現実的な落とし所（コントロール方法）が分かる。
企業がAIを導入する際の最大の壁が、実は技術力ではなく「組織の設計」（業務プロセスやチームのあり方）にあるとされる理由が腹落ちする。
話の地図はこうです。まず、日本企業４社の事例を、AI導入の深さ順に見ていきます（第４章）。次に、海外勢ながら日本でも馴染み深いCanvaの大規模運用の教訓を掘り下げます（第５章）。
※なお、この記事には「IaC」や「MCP」などの高度な技術用語も登場しますが、すべて直感的な例えで解説しています。非エンジニアの方も、技術の仕組みそのものではなく「AI導入における組織の壁」という本質に着目して読み進めてみてください。
第４章｜日本企業の現在地
楽天・メルカリ・みずほ・NRI
■ 楽天 「AI化」を経営の仕組みに変えた先行者
このイベントで最も多く名前が挙がった日本企業は楽天でした。基調講演、対談、単独講演と、登場機会は３回に及びます。
楽天は自社のAI戦略を「AI-nization」（エーアイナイゼーション / AI化）と呼んでいます。AI for Business担当ジェネラルマネージャーの梶裕介氏は、その本質を「モデルの能力曲線（AIの進化のスピード）と、現実の業務とのギャップを埋める活動」だと説明しました。新しいモデルが出るたびに、既存の業務にAIを”ちょい足し”するのではなく、ワークフロー（業務の流れ）そのものをAI前提でゼロから設計し直す。これを毎月、あるいは四半期ごとに繰り返しているといいます。
その成果は、圧倒的な数字に表れています。Anthropic公式の事例ページによれば、楽天は複雑なオープンソースの改修プロジェクトにおいて、なんと「７時間連続の自律コーディング」を達成しました。結果として、新機能の市場投入までの期間を24営業日から5日へ、実に79%も短縮したのです。
もちろん、こうした華々しい成功の裏には、当然ながら語られなかった無数の失敗プロンプトや、幻覚（ハルシネーション）による手戻りの試行錯誤があったはずです。しかし、その泥臭い検証の壁を組織単位で乗り越えたからこそ得られた、圧倒的な競争優位性と言えるでしょう。
梶氏自身も、単独セッションでその劇的なスピードの変化を次のように語っています。
「かつては四半期、３ヶ月に１回主要リリースをしていたのが、今ではかなりスピードが上がって、2週間ぐらいでできるようになりました」
Rakuten's AI-nization: Autonomy × empowerment
現場でAIを真に活躍させるため、楽天は３つの柱を立てています。
★ 第一の柱は、「評価の自前主義」です。
楽天は「楽天SWEベンチ」と呼ぶ自社版の性能測定試験を持ち、自社のシステムで実際に作られたプルリクエスト（コード変更の申請）を、AIエージェントが人間の助けなしにどれだけ解決できるかを測っています。しかも、楽天が測るのは単なる「正答率」だけではありません。
１タスクあたり100円かかったのか、80円でできたのかというのを、トークンあたりではなくて『タスクあたりで計測する』というのを日々のスタンダードとして計測をしています。
Rakuten's AI-nization: Autonomy × empowerment
★ 第二の柱は、「複利の改善」です。
AIエージェントに「メモリ」（記憶）と「ドリーミング」（過去の作業を振り返って学びを書き残す仕組み）を持たせる前、初期のエージェントは重大なエラーを多く出していました。しかし、この自己改善の仕組みを組み込んだ結果について、梶氏はこのように明かしています。
パイロットで検証してみた結果、これはちょっと良すぎる数字かもしれないんですが、97%のクリティカルエラー（重大エラー）の削減ができました。［中略］１日に１%でも改善していけば１年で複利的に大きな差になる。プロセス・仕組みとしてそういったエージェントが日々改善していくような仕組みを持つことが、ビジネス価値を最大化する上で重要です。
Rakuten's AI-nization: Autonomy × empowerment
★ 第三の柱は、横軸を広げる「ガリレオ」構想です。
かつての天文学者ガリレオ・ガリレイのような万能人のように、「一人の人間がいくつもの専門職種をカバーできるようになる」という意味を込めた社内の呼び名です。
例えば、プロダクトマネージャー（企画担当）が、いちいちエンジニアにデータ抽出を依頼するのではなく、自らAIに自然言語で指示を出してクラウド上のログからデータ分析の仕組みを組み、異常検知を行えるようになりました。これにより、エンジニアチームは雑務から解放され、より高度な技術的基盤を作る作業に集中できます。
さらにその先として、夜間も常時監視して問題を自律的に直す「アンビエントエージェント／オーバーナイトエージェント」（眠らない同僚）を、本番システムへ広げることに今いちばん力を注いでいるそうです。
当然ながら、人間の監視なしにAIが本番環境へ直接手を入れることは、一歩間違えればシステム障害に直結する強烈なリスクを伴います。楽天がこれを視野に入れられるのは、彼らが前述の「徹底した評価の仕組み」（SWEベンチ）や「インフラのコード化」（IaC）といった、暴走を防ぐための極めて強固な安全網をすでに敷き終えているからに他なりません。
そして講演の核心は、技術論ではなく「組織論」でした。
梶氏の以下の言葉は、この日のイベント全体を通しても屈指の本質的な指摘です。
仮に解くべき課題が100個あったとして、それが80個しか解けないとして、じゃあなぜ残りの20個が解けないのかっていうのを紐解いていったときに。多く残るのはモデルの知能が足りないからではなくて、何かしらそれをブロックしている制約になっているものが組織の構造上、組織のデザイン上あるというのがほとんどのケースです。
Rakuten's AI-nization: Autonomy × empowerment
「AIの限界（天井）を決めるのはワークフローの設計であって、モデルの知能ではない」。この壁を越えるため、楽天は以下の３つの「制約解除」に全社で取り組んでいます。
インフラのIaC化（コードによる自動管理）
インフラが人間用の「管理画面」（マウス操作）でしか操作できないとAIは手を出せません。AIが直接操作できるよう、設定をプログラム（コード）で管理できるようにすること。
つまり、AIをチームの同僚として迎え入れるためには、まず人間用の「画面のポチポチ操作」という仕事のやり方を廃止し、AIが直接読み書きできる「テキスト」（コード）での仕事環境へ整え直してあげる必要がある、ということです。ルールとポリシーのアップデート
社内のルールを「AIエージェントが自律的に動くこと」を前提としたものに作り変えること。コンテキスト（業務知識）の安全な連携
最も重要な社外秘データをAIに安全に渡すため、セルフホスト型サンドボックスやMCPトンネルといった最新技術を活用すること。
また、発表当日の新モデル「Fable 5」についても、さっそく自社の業務でテストしたリアルな所感が語られました。
何かをやった後にセルフベリフィケーションをする、自分で確認をする。（中略）タスク完了率は正直あまり変わらなかったとしても、そこに行くまでのコストであるとかトークンエフィシエンシー（使ったトークン数のわりに、どれだけ有用な結果を出せたか）というのが大きく改善されました。
Rakuten's AI-nization: Autonomy × empowerment
モデルが自分の作業を自発的に振り返って修正するようになったことで、無駄な失敗が大幅に減ったという現場の生の声です。
【用語解説】
○ IaC（Infrastructure as Code / インフラストラクチャ・アス・コード）
サーバーやネットワークなどの構築を、手作業の画面操作ではなく、プログラム（コード）を書いて自動的に構築・管理する手法。これによってAIもインフラを操作できるようになります。
○ CI（Continuous Integration / コンティニューアス・インテグレーション：継続的インテグレーション）
○ CD（Continuous Delivery / コンティニューアス・デリバリー：継続的デリバリー）
ソフトウェアの変更（コードの修正）を常に自動でテストし、本番環境へ安全に配信（リリース）し続けるための開発の仕組み。
○ MCP（Model Context Protocol /モデル・コンテクスト・プロトコル）
AIが社内のデータベースや外部ツール（NotionやSlackなど）に安全にアクセスして情報を取ってくるための、共通の「接続ルール」のこと。例えるなら、AIに社内システムへの「共通の入館証」を渡すような技術です。
■ メルカリ エンジニアリング組織全体がAIの上で動く
楽天、みずほ、NRIが自社の担当者によって具体的な取り組みを語ったのに対し、フリマアプリ大手のメルカリはこのイベントに自社で登壇したわけではありません。Anthropicの基調講演の中で、Claude Codeの製品責任者であるキャット・ウー（Cat Wu）氏が、自身の英語でのスピーチ中に「特筆すべき世界の成功事例」のひとつとして短く紹介しました。
しかし、Spotifyなどのグローバル企業に続けてウー氏が語ったその短い報告は、参加者に強烈なインパクトを残しました。
At Mercari, the entire engineering team runs on Claude Code. And they've measured that engineering output is up 90% year-over-year using the tool.
（意訳）メルカリでは、エンジニアリングチーム全体がClaude Codeを使って開発を行っており、このツールを利用した結果、エンジニアリングの生産性（アウトプット）が前年比で90％向上したと測定されています。
前年比90%増という数字は、一見すると「コードの量が２倍近くに跳ね上がったのか？」と疑いたくなるほどの劇的な変化です。もちろん、ベンダー側のイベントでの発表数字であるという前提は差し引く必要がありますが、それにしても見過ごせないインパクトがあります。
では、この圧倒的な成果の裏側には、どのような泥臭い運用の工夫があったのでしょうか。
実は、この驚異的な数字を支える具体的な仕組みについて、イベントの短いスピーチ内では詳細まで語られませんでした。そこで、ここからはイベントの枠を超え、メルカリが公開している技術ブログ『mercari-pm-agent Design — Automating the PM Workflow with Claude Code Skills and MCP』（mercari-pm-agentの設計――Claude CodeのスキルとMCPによるPM業務の自動化）で公開されているPMインターン生が開発した「mercari-pm-agent」の設計（Claude Codeのスキル活用）の裏側を見ていきます。これが現代のAI活用の手本として非常に示唆に富んでいます。
★【課題】情報収集に奪われるPMの時間
PMが新しい機能を企画する際、社内のさまざまなツールを横断して情報を集める必要があります。「Notion」で中期戦略やKPIを確認し、「Slack」で社内からの要望を拾い、「Looker」（データ分析ツール）で定量データを確認し、「Figma」で現在の画面デザインを見る。これらを整理してPRD（製品要件定義書）にまとめる作業には、膨大な時間がかかっていました。「PMの時間は、情報をかき集めることではなく、深く考えて意思決定することに使うべきだ」。このモチベーションから「mercari-pm-agent」は生まれました。
★ 解決策と４つの技術的ブレイクスルー
このエージェントは、MCP（AIと社内ツールをつなぐ規格）を使ってこれらすべてのツールをClaudeに接続し、「課題の発見 → データ収集 → PRDの作成 → UIのモックアップ作成」という一連のワークフローを自動完結させます。開発において、彼らは以下の４つの高度な工夫を行いました。
① MCPの並列接続による高速化
データ収集のステップにおいて、複数のMCPツール（Notion、Slack、Lookerなど）を順番に検索するのではなく、「並列（パラレル）に検索する」というルールをAIに指示しています。これにより待ち時間を大幅に削減し、一部のツールが応答しなくても処理が止まらない頑健性（ロバスト性）を持たせています。
② 関心事の分離（Separation of Concerns）による精度向上
評価を繰り返す中で直面したのが、「指示書（プロンプト）のファイルが長くなるほど、AIの出力精度が落ちる」という問題でした。長い文章の途中にある情報がAIに無視されてしまう「Lost in the Middle」と呼ばれる現象です。これを解決するため、ソフトウェア開発の基本原則である「関心事の分離」をプロンプト設計に応用します。
『AIが何をするか』（行動ルール）だけをメインのファイルに書き、具体的な『データやテンプレート』は別のファイルに分けて保存し、AIが必要な時だけ参照するように設計を直しました。この構造変更だけで、AIの精度は劇的に向上したといいます。
③ 評価基準の事前定義（プロンプトTDD）
AIの出力は「なんとなく良さそう」という主観的な評価になりがちです。そこで開発チームは、実装の前に客観的な評価基準を定めました。そして、この基準に沿ってエージェントの出力を自動採点する「評価専用のAIスキル」（skill-creator-max）を別に作成し、客観的なスコアに基づいてAIの行動を改善し続ける仕組み（テスト駆動開発の手法）を作りました。
ただし、この「AIにAIを評価させる」という高度な自動化は、一つ間違えると「最初の採点基準が間違っていた場合、AI同士で間違った正解を量産し続ける」（エコーチェンバーに陥る）という強烈なリスクを孕んでいます。だからこそ、大元となる「人間が定義する評価軸」が極めて重要になります。
④ 「人間がドライバーである」という厳格な制約
そして最も重要なのが、エージェントにすべてを自動で進めさせるのではなく、「何をやってはいけないか」（Must not do）という明確な制約ルールをAIに課した点です。AIに丸投げして「もっともらしい嘘」（ハルシネーション）をでっち上げさせるのではなく、集めたデータをどう判断するかは常に人間が「意思決定のドライバー」として手綱を握る。これこそが、AIを実際の業務フローに安全に組み込むための極めて実践的なアプローチです。
また、AIが社内中のツール（NotionやSlackなど）を自由に横断できるということは、「そのAIにどこまでのアクセス権限を持たせるか（経営情報は見せない等）」という、新たなセキュリティ設計の壁が生まれることも意味しています。
開発の現場で「便利な道具」として使う段階から、職種を横断した「組織の業務基盤」（インフラ）になる段階へ。楽天が経営の仕組みとしてトップダウンで取り組むのに対し、メルカリは現場からのボトムアップの浸透が組織全体を覆い尽くし、圧倒的な成果を生み出した好例と言えます。
ここで特筆すべきは、トップダウンの楽天とボトムアップのメルカリという全く異なるアプローチをとる２社が、「奇妙な一致」を見せている点です。
楽天のPMが自らデータ分析を行う「ガリレオ構想」と、メルカリのPMインターン生が開発した情報収集エージェント。
これらはどちらも、「企画職（PM）がAIの力を借りることで、これまでエンジニアやデータアナリストの専売特許だった領域へと越境し始めている」という、職種の壁の融解を示しています。各社が個別に発表した事例を並べると、一部の先進企業だけでなく、ビジネス全体で起きている不可逆な変化の輪郭がはっきりと浮かび上がってきます。
【用語解説】
○ スキル（Skill）
Claude Codeに「こういう手順で仕事をしてね」と教え込むための独自の拡張機能（マニュアル）のこと。
○ MCP（Model Context Protocol）
AIが社内のデータベースや外部ツール（NotionやSlackなど）に安全にアクセスして情報を取ってくるための、世界共通の「接続ルール」（窓口）のこと。
○ PRD（製品要件定義書）
「どんな製品（機能）を、なぜ、どのように作るのか」をまとめた設計図のこと。
○ 関心事の分離（Separation of Concerns）
プログラムを作るときに「役割ごとにファイルを綺麗に分ける」という基本ルール。AIへの指示書も、長すぎるとAIが混乱するため、「やることリスト」と「参照データ」を別ファイルに整理整頓することが重要だと分かってきました。
■ みずほ 金融機関が挑む「AI前提」の業務再設計
メガバンクグループのみずほからは、執行役員デジタル戦略担当（Chief AI Officer）の藤井達人氏と、内製開発チーム（ラボ）をリードする染谷健太郎氏が登壇しました。金融機関という極めて厳格なルールが求められる環境で、いかにしてAIを全社導入するかという「エンタープライズAIの最適解」を示すセッションです。
藤井氏が冒頭で掲げたメッセージは、みずほのAIに対する哲学を端的に表していました。
AI活用ではなくて、AI前提の業務プロセスに再設計をしていくということですね。既存業務にAIを足すことでは当然目標としてないと。そうではなくて、AIがいることを前提に業務プロセスそのものを組み替えていくということが重要だというふうに思っています。
Building an AI-native engineering organization at Mizuho
既存の業務にAIを”便利なツール”として付け足すのではなく、AIが中心となって業務の流れ全体（エンドツーエンド）を回し、人間は「設計・監督・例外対応」に回る世界を作るという宣言です。藤井氏はこの変革の背景について、「今のAIの進化スピードを考えれば、5〜10年先にAGIやASI（超知能）が実現していないと考える方が不自然だ」と踏み込み、その未来の世界から逆算して、今のステップを設計していると説明しました。
この「AI前提の業務再設計」を実現するため、みずほは「エンタープライズAIモデル」と呼ぶ４つの強固な柱を構築しています。
Mizuho AI-OA（AI Oriented Architecture）
AIエージェントを開発するための全社的なルールや標準化、ガバナンス（統制）の土台。WizBase（ウィズベース）
AIモデルと社内データを安全に接続する、AWS上に構築された共通インフラ基盤。内製開発チーム
企画（PO）と開発（DEV）、R&Dが一体となってスクラムを組み、素早くAIアプリを形にする体制。AI Agent Factory（AIエージェント工場）
エージェントを確実に・継続的に・効率的に量産するための加速装置。
藤井氏は、この枠組みの狙いを次のように表現しました。
単にアプリとか単体のエージェントを作るのではなくて、安全に早く繰り返し作れる『企業能力』を作っているというふうに捉えていただけるといいのかなと思っています。
Building an AI-native engineering organization at Mizuho
実際、社内ではすでに数十から100を超えるAIエージェントが稼働しており、その多くがClaude Codeによって作られているといいます。
続く染谷氏のパートでは、現場の生々しい数字と開発手順が明かされました。現在、40名いる内製開発チームの全員にClaude Codeが展開されており、「１〜５名の少人数のチームで、現在25個のプロダクトを並行して開発している」という、金融機関のイメージを覆す驚異的なスピードで動いています。
モデルはすべて「Amazon Bedrock」（AWSのAIモデル提供サービス）に集約。これにより、厳しいセキュリティ監査を効かせつつ、Opus 4.7や4.8といった最新モデルを提供当日からチームへ展開できる体制を整えました。
金融機関から当日に（新モデルを）活用できるっていうのは、なかなか想像されるより早いのかなと思います。今日出たFable 5もちょっと気になって色々見ておりましたが、あれはいろいろ確認してから活用を進めようかなと思っております。
Building an AI-native engineering organization at Mizuho
「新モデルを当日に使える」というスタートアップ並みの自負と、「未知のモデル（Fable 5）は安全を確認してから」という慎重さの同居。これこそが規制産業のリアルな最前線です。
みずほの開発の現場で特に光っている工夫が、「コンテキスト（文脈・ルール）の多層注入」です。染谷氏らのチームは、Claude Codeにただコードを書かせるのではなく、「Anthropic公式のフロントエンド（画面デザイン）スキル」「AWSのインフラスキル」に加え、「みずほ独自のセキュリティルールや開発規約」を多層に重ねて読み込ませ、それを専用のプラグインとして全エンジニアに配布しています。
単にエージェントにコードを書かせているだけではなくて、こういう（みずほ固有の）コンテキストを読み込ませた上で開発を進めているという点になります。
Building an AI-native engineering organization at Mizuho
開発フローにおいては、「/plan」（設計の壁打ち）→「/tdd」（テスト先行の実装）→「/pr」（レビュー申請文の作成）といったClaude Codeのスラッシュコマンド（定型指示）を使いこなしつつ、途中で「みずほのルール上問題ないか」をAIにセカンドオピニオンとしてチェックさせています。
※この「テスト先行の実装」は、まさにメルカリが実践していたTDDと同じアプローチです。
AIがルール違反のコードを書くことを未然に防ぎ、人間の手戻りを極限まで減らすこの仕組みこそが、25個のプロダクトを同時に開発できるスピードの源泉なのです。
締めくくりに、藤井氏から今後を見据えた２つの自社プロジェクトが紹介されました。
ひとつは「みずほLLM」です。これはオープンウェイトモデル（中身が公開されたAI）をベースに、金融のガイドラインや法令の考え方を学習させた独自の専門モデルです。データの機密性を完全に守りながら、Claudeのような大型モデルと組み合わせて専門業務をこなすことを目的としています。
「絶対にクラウドへ出せない最高機密データ」は手元のオープンウェイトモデルで処理し、「高度な推論」はClaudeに任せるという、金融機関ならではの現実的なハイブリッド戦略と言えます。
もうひとつは、法人・個人営業（RM）を支援するAIエージェント「RM Studio」です。顧客への提案前の膨大な情報収集や分析をAIが肩代わりし、若手とベテランの「引き出しの差」を平準化することで、提案準備などにかかる営業活動の生産性を２倍以上に引き上げることを狙っており、すでに現場で大規模なPoC（実証実験）が進んでいます。
※ここでいう生産性とは「売上が２倍になる」という魔法ではなく、「裏側の泥臭い検索・分析作業の時間が半分以下になる」という極めて現実的な指標です。
今後２年間、みずほは「ビッグロックス」（Big Rocks＝行く手を阻む大きな岩）、すなわち顧客価値を生む上で障害となっている重要プロセスを見極めて集中的に攻略していくといいます。人間の作業にAIが入り込む「ヒューマン・イン・ザ・ループ」から、AIが自律して働き人間は外から監督するだけの「ヒューマン・オン・ザ・ループ」へ。金融機関の巨大なシステムが、確実にAIネイティブへと変貌しつつあるロードマップが示されました。
【用語解説】
○ AGI（Artificial General Intelligence / アーティフィシャル・ジェネラル・インテリジェンス）
○ ASI（Artificial Superintelligence / アーティフィシャル・スーパー・インテリジェンス）
AGIは「人間と同じくらい何でもできる汎用AI」、ASIは「人間の知能をはるかに超える超知能」のこと。
○ スクラム（Scrum）
企画担当（PO）と開発担当（DEV）が密にコミュニケーションを取りながら、短い期間で開発と改善を繰り返す手法。
○ オープンウェイトモデル
AIの脳内（パラメータ）が一般公開されているモデルのこと。企業が自社の安全なサーバー内部に持ち込み、独自の社外秘データやルールを追加で学習（ファインチューニング）させやすいメリットがあります。
○ PoC（Proof of Concept / プルーフ・オブ・コンセプト：概念実証）
新しいアイデアや技術が、本当に実際のビジネスで役立つか（実現可能か）を小さく試してみるテストのこと。
■ 野村総合研究所（NRI） 「モデルではなく、業務との相性を評価する」
日本企業事例の最後を飾ったのは、野村総合研究所（NRI）のAIソリューション推進部長、北村勇気氏のセッションです。NRIは、自社だけでなく様々な業界の顧客企業へAI導入を支援する立場から、ベンダー（提供企業）のイベントとしては異例なほど率直で、極めて冷静な視点を提示しました。
あらゆるタスクで、常にClaudeを選んでいるわけではもちろんないです。例えばリアルタイムに翻訳したいっていうタスクにおいては、当然他のモデルが勝るケースもあります。［中略］モデルを評価するというよりは、業務に対してどのモデルが一番フィットするかっていうのを評価していると。
How NRI picks models with business-task benchmarks: A continuous eval loop for enterprise adoption
世の中には、AIの性能を測るための「パブリックベンチマーク」（公開されている共通テスト）が溢れています。しかし北村氏のスタンスは一貫しており、「共通テストの点数の高さだけでモデルの優劣が決まるわけではなく、目の前の泥臭い業務にどれだけ適性があるかがすべてである」と言い切ります。
そのための評価の仕組みも非常に実践的です。NRIでは新しいモデルが出ると、ほぼ即日で自社の業務ベンチマーク（テスト）を走らせています。当日朝に発表されたばかりの「Fable 5」についても、「当然ながら社内の方でも評価走っております」と明かされました。
NRIが測っているのは、テストの点数ではなく、業務に潜む「読んで詰める」仕事への適性です。
約款や社内規程のような、日本語の複雑で大量の業務文書を正しく解釈できるか。
紙の帳票や非定型のフォームを、OCR（文字認識）と組み合わせて正確に読み取れるか。
そして最も重要なのが、知識が足りないときや推論の過程がおかしいときに、「わからない」「論理的におかしい」と自分から言える能力があるかです。
現在のAIは構造上、もっともらしい嘘（ハルシネーション）を自信満々についてしまう傾向があります。だからこそ、自身の限界を自覚して立ち止まれる「知的謙虚さ」を備えているかどうかが、実業務を任せるエージェントとしての究極のリトマス試験紙になるのです。
またエンタープライズ特有の注意点として、Fable 5のような強力な新モデルを導入する際は、利用環境によって「データ保持の扱い」（ZDR＝ゼロデータリテンションの可否）をしっかり確認すべきという、現場ならではの実務的な指摘もありました。
【用語解説】
○ ZDR（Zero Data Retention / ゼロ・データ・リテンション）
企業が入力した機密データを、AI企業側が「一切保存せず、AIの学習にも使わない」という法人向けの安全な契約ルールのこと。通常のAPIではZDRが適用されますが、Fable 5のような「悪用されると危険な能力を持つモデル」では、安全監視のために一時的にデータが保存される仕様（30日間の保持など）になっている場合があるため、機密情報を扱う際はポリシーの確認が必要になります。
★ Claudeが選ばれる理由：「複雑な指示への追従性」
では、そうした厳しい目を持つNRIが、数あるAIの中で「なぜClaudeを選定の上位に置くのか」。北村氏が挙げた最大の理由は「複雑な指示への追従性」でした。
かなり複雑な業務指示、前提、制約、そういったものを丁寧に読み込んで解釈して実行できると。こういった点、非常にClaudeの強いところだなというふうに評価しております。
How NRI picks models with business-task benchmarks: A continuous eval loop for enterprise adoption
実際の業務には、法令、社内規程、個別のレギュレーションが幾重にも重なっています。これらを１回で正しく読み込んで実行できる能力は、そのまま「ビジネスの価値」に直結します。
これまでAIを業務に組み込む際は、人間が常にチェックして修正を指示する「ヒューマン・イン・ザ・ループ」（人間が作業の輪の中に入る）が推奨されてきました。しかし、Claudeのように複雑な指示を正確に守れるモデルであれば、人間が要所に入る回数を大幅に減らすことができます。これが実現できれば、単なるコスト削減だけでなく、「業務のリードタイム（処理にかかる時間）そのものがギュッと縮む」からです。
北村氏自身も、実際のプロジェクトでClaudeの進化を肌で感じた瞬間をこう語りました。
私が経験しているプロジェクトでも、仕様の矛盾点をClaudeに指摘されたことがありまして。ちょっと『とうとうここまで来たか』というようなのが顕著に出てきたりしてます。
How NRI picks models with business-task benchmarks: A continuous eval loop for enterprise adoption
★ 提言：評価を「パイプライン化」し、業務単位のルーブリックを作れ
北村氏は最後に、AI導入を成功させるための実践的なアドバイスとして、まさにその「人間が担うべき最も重要な役割」である「評価設計」（Rubric / ルーブリック）の重要性を挙げました。
AIに対して、「何問解けたか」という点数ではなく、業務単位で評価できる塊を作ること。そして「人間がやればどれくらいかかるか」というベースラインと、「何ができていればOKか」という完了条件を明確に言語化してモデルに与えること。
100%の正解ではないんですけど、『これぐらいできてたら業務としては成り立つんで許容する』とかですね、あくまで業務目線で評価を設計していただく。
How NRI picks models with business-task benchmarks: A continuous eval loop for enterprise adoption
これを「ルーブリック」（採点基準表）や、Claude公式ドキュメントにある「Define Outcomes」（アウトカム定義）の形でAIに与える。スクラム開発において「バックログ（課題リスト）に完了条件をしっかり書く」のと同じ感覚だという説明は、多くの実務者に響いたはずです。この評価基準をあらかじめ「パイプライン」（自動実行できる仕組み）にしておけば、今回のように新しいモデルが出たその日のうちに、自社の業務にすぐ使えるかを判定できるようになります。
この仕組みを回し続けた実績として、人間が担っていたダブルチェック業務をほぼAIに置き換え、効率を50%も高めた事例（Anthropic公式のケーススタディにも掲載）が紹介されました。
「AIの利用をトークン単位ではなくタスク単位（仕事の成果）で測る」「業務をAI前提で再設計し、自己評価の仕組みを持つ」。NRIが提示したこのアプローチは、楽天が自社ベンチマークの構築から導き出した結論と、全く別の道筋から同じ本質（真理）にたどり着いている点が非常に印象的でした。
【用語解説】
○ ヒューマン・イン/オン・ザ・ループ（Human-in/on-the-Loop）
AIの作業に人間がどう関わるかの違い。「イン」（In）は人間がつきっきりで手伝う状態。「オン」（On）はAIが自律して働き、人間は最後にハンコを押す（監督する）だけの手離れが良い状態を指します。
○ ルーブリック（Rubric）
もともと教育分野で使われる「採点基準表」のことで、「何がどのレベルでできていれば何点（合格）か」を言語化したもの。AIエージェントは「良い仕事の定義」を渡されると自分で出来栄えを検証しながら働けるため、ルーブリック作りは「AI時代の管理職の必須スキル」そのものだといえます。
○ スクラム開発（Scrum development / スクラム・デベロップメント）
○ バックログ（Backlog）
短期間で開発と改善を繰り返す開発手法（スクラム）において、チームが「やるべき作業リスト」（バックログ）に、「どういう状態になればこの作業は完了と言えるか」（完了条件）を明確に書き込むルールのこと。
第５章｜Canvaの教訓
数千万人にAIを届ける現実解
日本企業の事例に続いて登壇したのは、世界中で数千万人が利用するデザインツール「Canva」のAI製品責任者、ダニー・ウー（Danny Wu）氏です。Canvaは、裏側に何百ものツール（背景切り抜きや画像生成など）を組み合わせた、極めて複雑なAIエージェントシステム「Canva AI 2.0」を構築しています。
ここでぜひ注目していただきたいのは、第４章の「みずほ」が厳格なルールを多層に重ねてAIを制御するアプローチをとったのに対し、「Canva」はこれから語るように、細かな制御（ハーネス）をあっさりと手放すアプローチをとっている点です。両極端とも言えるこの違いは、AI実装において「唯一の正解」はなく、自社の事業ドメインに合わせた設計がいかに重要かを浮き彫りにしています。
また、もう一つ決定的な違いがあります。第４章の日本企業が主に「自社の社員の生産性を高めるため」にAIを活用しているのに対し、Canvaは「数千万人の一般ユーザー」（しかも多くが無料）にAIを提供しなければならない点です。「高給なエンジニアの業務時間を削るための投資」と「無料ユーザーにシステムを使わせ続けるためのコスト」では、１回のAI操作に対して許容できる予算のシビアさが全く異なります。
ウー氏の講演は、この日の中で最も「AI運用の生々しさ」に踏み込んだ内容でした。数千万人のユーザーを抱えるCanvaの過酷な環境を、ウー氏はこう表現します。
the vast majority of Canva users are free, and we believe it's really, really important to be able to offer AI to everyone, to students, to people who might not be able to afford, say, upgrades to Canva right now.
（意訳）Canvaのユーザーの大多数は無料版を利用していますが、私たちはAIをすべての人、特に学生や、今すぐCanvaのアップグレードにお金を出せない人々にも提供できることが、非常に重要だと考えています。
「無尽蔵にコストをかけられるわけではない中で、いかにしてAIの品質とコスト（費用）の最適解を見つけるか」。その徹底した工夫が語られました。
■ 「平均的なデザインは110回編集される」
まず品質の話から。ウー氏は「ユーザーが壮大な指示文を打ち込み、そこから一発で完璧なデザインが出てくるのは夢だが、現実は違う」と断ったうえで、デザインは本質的に主観的であり、正解がひとつではないと指摘します。
For example, the average Canva design is edited about 110 times before it's been published. (...) it's really something that can work with you, something that you can steer, something that you can really walk alongside as a super design collaborator.
（意訳）例えば、Canvaで作るデザインの平均では、公開されるまでに約110回編集が行われています。 (中略) つまり、AIはあなたと協働し、あなたが方向性を操作でき、本当に『スーパーデザイン協働者』（コラボレーター）として、あなたと並んで歩んでくれる存在なのです。
完成品を黙って差し出す「下請け」ではなく、途中で方向を変えられる「協働者」にする。さらにCanvaのデータでは、ユーザー満足度は「AIの品質指標」（出力の美しさ）よりも「レイテンシー」（応答の速さ）と強く相関することが分かったといいます。
コンピューターに時間をかけて計算させれば、もう少し上質な初稿は出せます。しかし、多くのユーザーは「待たされること」を嫌います。「効率的フロンティア」、つまり「品質」と「速さ」の最適な妥協点（一番ユーザーが喜ぶスイートスポット）を探すことが、設計の中心になりました。
※もちろんこれは、ただ単に「早くて質の低いコンテンツの粗製乱造」（AI Slop）を許容するという意味ではありません。妥協した品質が「最低限の底」を絶対に割らないよう、強力な防波堤として機能しているのが、次に語られる「Evals」の存在です。
■ 「今日の賢いハーネスは、明日のデッドコード」
次にウー氏は、世界のエンジニア界隈で今後長く引用されそうな、耳の痛い名言を残しました。
I think today's clever harness is really tomorrow's dead code. (...) harnesses are getting more and more disposable. Don't get attached. Don't fall in love with them. Evals are what really matters.
（意訳）今日のカバーリングハース（テスト用のHarness）は、明日には使われなくなった「デッドコード」（不要なプログラム）になるでしょう。
(中略）
ハーネスはどんどん使い捨てられがちになっています。それに執着したり、ハーネスを愛しすぎたりしないでください。本当に重要なのは、Evals（評価）です。
Canvaは過去３年間で、AIハーネスを少なくとも３回、全面的に書き直したそうです。
初期はAIの能力が低かったため、「どう思考するか」の手順を人間が細かくプログラムで指示（制御）していました。しかし、モデル自身が賢くなるたびに、昔の人間が良かれと思って作った細かな指示が、逆にAIの足かせ（制約）に変わってしまいます。だからこそ、「仕組み作り」に愛着を持たず、Fable 5のような強力な新モデルが出たときは、「今の複雑なプログラムはもう捨てて、AIの知能に任せられないか」を再評価する絶好の機会だと説きます。
では、プログラムが使い捨てになるなら、企業は何を「資産」として残すべきか。その答えが「Evals」（イーバル＝AIの出来栄えを測るテスト）です。 Canvaでは、単機能のテストではなく、メモリや外部ツール連携まで含めた最初から最後までの流れを測る「エンドツーエンド評価」を重視し、テストケースを十数件から数百件へと育ててきました。
興味深いのは、その「テスト問題の作り方」です。画像の高解像度化機能（アップスケーラー）を刷新した際、社内の評価テストでは100点満点だったにもかかわらず、一部のユーザーから強い不満が寄せられました。ウー氏は、「社内で想像したテスト問題よりも、早期にユーザーへ公開して集まった『実際の苦情や失敗例』こそが、Evals（評価テスト）に加えるべき最高の題材だ」と語り、苦情をすべてテストに組み込み、それをクリアできるように指示書（プロンプト）や仕組みを修正し続けることで、課題を解決した経験を共有しました。
前の第４章のNRIが「事前に人間が強固な基準（ルーブリック）を作る」というトップダウンの評価だったのに対し、Canvaは「膨大なユーザーの苦情から事後的にテストを鍛え上げる」というボトムアップのアプローチをとっています。ここにも、対象読者や事業環境に応じた「AI運用の現実解の違い」が鮮明に表れています。
■ トークン予算とモデルの使い分けで、コストはほぼ半分に
数千万人の無料ユーザーを支えるための「コスト管理」の話は、極めて具体的で実践的でした。柱は３つあります。
第一の柱は「ターン予算」（Task budgets）です。
ユーザーは時として、「この100ページの資料が最高に良くなるまで作業し続けて！」といった、終わりが見えない曖昧な指示を出します。
Frontier models will do an amazing job at it with unlimited time and with unlimited budget. But if you don't have unlimited usage or budget... setting constraints and actually instructing the model and giving a bit of a budget to complete a term really does help.
（意訳）最先端のモデルは、時間と予算が無限であれば、その任務を驚くほど上手にこなします。しかし、使用量や予算が限られている場合は……制約を設定し、実際にモデルに指示を与え、特定の課題を完了するための予算（バジェット）を少し与えることが、本当に効果的です。
AIにすべてを任せると完璧を目指して暴走し、同じ失敗を繰り返す「ドゥームループ」（死のループ）に陥って、莫大なコスト（トークン）を消費してしまいます。
そこで、１回の作業に使えるトークン量（例えば32,000など）をあらかじめAIに伝え、配分を任せます。途中で「もう半分使ったぞ」と警告し、上限に達したら無理にでも作業をまとめさせることで、コストの爆発を未然に防ぎました。
第二の柱は、「サブエージェント」によるモデルの使い分けです。
文字の修正のような単純作業に、一番賢くて高価なモデルを使うのは無駄です。Canvaは最初、依頼の難易度に応じてリクエストを安いモデルへ振り分ける方式（モデルルーティング）を試しました。しかし、ここに大きな落とし穴がありました。
every time we switch models we have to write the cache again... so we moved to a sub agents approach and this is ultimately what worked best for us.
（意訳）モデルを切り替えるたびにキャッシュを再度書き直す必要がありました。（中略）
そこで、サブエージェント（部分エージェント）というアプローチに移行しました。これが、最終的に私たちにとって最も効果的な方法でした。
「プロンプトキャッシュ」とは、AIに読み込ませた長文の前提知識を記憶させておき、料金を10分の1に割引する画期的な仕組みです。
しかし、途中でAIの頭脳（モデル）を切り替えると、この記憶がリセットされてしまい、再度読み込み料金が発生してかえって損をしてしまったのです。
最終的にCanvaは、文脈（記憶）を持つ主役の親エージェント（Sonnet）を据え置き、難しい仕事は上位モデル（Opus）の、簡単な仕事は下位モデル（Haiku）の「サブエージェント」（部下）に委任し、結果だけを親に戻させる構成に落ち着きました。これにより、キャッシュの命中率は常に80〜90%台を保ち、品質を落とすことなく運用コストをほぼ半減させることに成功しました。
第三の柱は、「可視化」です。
Canvaでは、社内スタッフが使う検証画面の端に「この１回の操作にいくら（何円）かかったか」を常に表示するダッシュボードを整えました。すると、「本来安いはずの単純な操作が、なぜか異常に高いコストになっている」という、システム側のバグや設計ミスにすぐ気づけるようになったといいます。「コストを恥ずかしがらずに常に見える化することが、結局は品質改善の最短ルートになる」という、逆説的で力強い教訓でした。
AIエージェントに泥臭い作業や推論を委譲すればするほど、最終的に「どの評価基準を正とし、誰がその出力に責任を負うのか」という、人間側の『知的・主権』がこれまで以上に鋭く問われることになります。AIの魔法が解けた今、私たちが向き合うべきは、プロンプトのテクニックではなく、自社の事業と組織のあり方そのものなのです。
【用語解説】
○ ハーネス（Harness）
AIを思い通りに動かすために人間が書いた「補助器具・制御プログラム」。
○ デッドコード（Dead code）
システムの中に残っているけれど、もう誰にも使われなくなった不要なプログラムのこと。
○ Evals（エバルス）
AIの出力が正しいかどうかを自動で採点する「評価基準・テスト問題」のこと。
○ ドゥームループ（Doom loop）
AIが同じエラーや失敗を無限に繰り返してしまい、無駄なコスト（トークン）を大量消費してしまう「死のループ」。
○ プロンプトキャッシュ（Prompt Cache）
一度読み込ませた長文データや前提知識をAIに「記憶」（キャッシュ）しておき、毎回読み込み直すコストと時間を節約する技術。Anthropicではこれを使うと入力コストが90%オフになります。AIに毎回分厚いマニュアルを一から読ませるのではなく、「一度読んだから覚えているよ」と記憶を保持させて、料金を最大90%オフにする割引の仕組みのようなものです。
○ サブエージェント（Sub-agent）
主役のAI（親）から一部の仕事を切り出されて働く、部下にあたるAI。親の記憶（キャッシュ）を汚さずに独立して作業できるため、安くて速いAIシステムを作るための必須テクニックとなっています。
⭐️【中編】のまとめと次回予告
Canvaが赤裸々に語った「使い捨てのハーネス」や「死のループ」といった泥臭い格闘の歴史は、決して彼ら特有のものではありません。前半で紹介した日本企業の華々しい成果の裏にも、当然こうした試行錯誤の山が築かれているはずです。
それらを踏まえた上で、日本企業４社（楽天、メルカリ、みずほ、NRI）とグローバル企業（Canva）の事例を並べてみると、AIエージェントを実務で成功させている組織の「３つの共通項」がくっきりと浮かび上がります。
第一に、公開ベンチマークを鵜呑みにせず、自社の業務で測る「自分たちの物差し」を持っていること。
世の中のAIテストの点数に一喜一憂するのではなく、楽天の「自社版SWEベンチ」や「タスク完了単価」、NRIの「業務単位のルーブリック」、Canvaの「エンドツーエンドのEvals」のように、「自分たちの泥臭い業務において何ができれば合格か」を定義し、自前の基準でAIを評価し続けています。
※ただし、この「自社専用のテスト問題」をゼロから作り、メンテナンスし続ける作業自体が、現場の優秀なエース社員の膨大な時間を食いつぶす、極めて過酷で泥臭いプロセスであるという残酷な現実も忘れてはなりません。
しかし、一度この「自前のテスト環境」を構築してしまえば、それは特定のAIベンダーへの依存（ロックイン）を防ぐ最強の盾になります。将来、Claudeよりも安価で優秀なモデル（例えばOpenAIやGoogleのGeminiの後継など）が登場した際、すぐに自社のテストを受けさせて乗り換えを判断できるからです。「自社で評価できる」ということは、テクノロジーの波に飲まれず、自社で主導権を握り続けるということと同義なのです。
第二に、過去の仕組み（ハーネス）や手順への愛着を捨て、モデルの世代交代のたびに作り直す覚悟があること。
Canvaの「今日の賢いハーネスは、明日のデッドコード」という言葉に象徴されるように、AIが数ヶ月で劇的に賢くなる以上、過去の細かな制御プログラムはすぐに不要な足かせになります。
ただし、これは「すべてを捨てろ」という意味ではありません。人間が書いた細かな「作業手順」（プロセス）は捨てるべきですが、楽天の「自社ベンチマーク」やCanvaの「Evals」（評価テスト）といった「結果の測り方」は、むしろ複利で積み上げていくべき最大の資産になります。過去の苦労や執着を捨てて、AIの知能に任せる範囲を常にアップデートし続ける柔軟さが求められます。
第三に、AIの失敗を「技術（モデルの知能）のせい」にせず、自分たちの組織側の「制約」（天井）を疑っていること。
楽天の「AIの限界を決めるのはワークフローの設計」、みずほの「AI前提の業務再設計」が示すように、100個の課題のうち解けない20個の原因は、AIのIQ不足ではなく、社内のインフラ権限やセキュリティルール、組織のプロセスそのものにあります。
彼らに共通しているのは、AIを「ただの便利なチャットツール」として扱うのをやめ、「明確なルールと評価基準を与え、自律的に働かせる同僚」（エージェント）として迎え入れている点です。
ここで語られたエンジニアリングの教訓は、実はすべてのビジネス部門に応用できる普遍的な組織論です。「評価の自前主義」や「ルールの再設計」は、決して開発現場だけの話ではありません。営業の提案書作成でも、人事の採用プロセスでも、本質的な壁は「AIモデルの知能」ではなく「人間の業務フロー」にあります。非エンジニアの方々も、ぜひこの視点を持ち帰り、ご自身の業務の「制約」を疑うことから始めてみてください。
では、こうした強力なAIやエージェントたちを、開発者たちは裏側でどうやって賢く、安く、情報をパンクさせずに動かしているのでしょうか？
いよいよ最終回となる【後編：開発実践ノウハウ編】では、これらの実践を裏から支える理論と最新技術に迫ります。
AIの自律的なタスク遂行能力が今どんな恐ろしい曲線で伸びているのか（第三者機関「METR」による最新研究を含む）、そして、API利用コストを９割（90%）も下げる「プロンプトキャッシュ」や、長時間の作業でもAIの記憶をパンクさせないための「コンテキストエンジニアリング」（ツールの動的検索や記憶の圧縮など）といった明日から使える具体技術を、初心者にも分かる言葉で徹底解説します。どうぞお楽しみに！
⭐️ 参考引用文献
◯『Code with Claude 2026 | Tokyo（ライブ配信アーカイブ）』− Anthropic（2026年6月10日、YouTube）本記事が依拠する一次資料。Canva講演（1時間56分頃）、楽天対談（2時間58分頃）、楽天単独講演（4時間31分頃）、みずほ講演（5時間16分頃）、NRI講演（6時間46分頃）を収録。第４章・第５章全体の根拠（各数値は登壇者の自己報告。楽天・みずほ・NRIの日本語講演はいずれも日本語字幕で全文確認済み）。
◯『Customer story: Rakuten』（導入事例：楽天）− Anthropic（公式事例ページ）７時間の自律コーディング、新機能の市場投入期間79%短縮（24営業日から5日へ）、部門横断の専門エージェント展開を報告。第４章・楽天の節の根拠（ベンダー公式事例のため、数値は当事者報告であり外部監査を経たものではない点に注意）。
◯『Claude Fable（製品ページ）』（クロード・フェーブル） − Anthropic（2026年、公式サイト）楽天・梶裕介氏の推薦コメント「最高のエフォートでは、Fable 5は自らの仕事を省察し検証する。それが高度に自律的なオペレーションを可能にする」を掲載。第４章・楽天の節の補強。
◯『mercari-pm-agent Design — Automating the PM Workflow with Claude Code Skills and MCP』（mercari-pm-agentの設計――Claude CodeのスキルとMCPによるPM業務の自動化）− Mercari Engineering（2026年4月、技術ブログ）プロダクトマネージャー業務を自動化するエージェントの設計を当事者が公開。第４章・メルカリの節の根拠（一次情報。導入範囲が職種横断に及ぶことの傍証）。
◯『New in Claude Managed Agents』（Claude Managed Agentsの新機能）− Anthropic（2026年6月9日、公式ブログ）楽天が言及したスケジュール実行とVaultの技術仕様。第４章・楽天の節（新機能活用）の根拠。
※この記事の構成や下調べにはAIを活用しています。