「AIに頼んだのに、思っていたのと違う」の正体

AIに仕事を頼んで、出てきたものを見て「うーん、なんか違う」と言った経験、ありませんか。

私は何度もあります。そして長いこと、その原因を「AIの能力がまだ足りないから」だと思っていました。でも、この1週間で読んだ3つの情報が、同じ答えを別々の角度から突きつけてきたんですよね。

原因はAIの能力ではなく、こちらの「渡し方」だった——という答えです。

3つの情報とは、食べログの技術ブログが公開したAI要件定義の事例、Claude Codeを作っている開発チーム自身の働き方の変化、そしてX（旧Twitter）で読んだ「AIへの依頼は作業指示書」という整理です。出どころはバラバラなのに、言っていることの骨格はひとつでした。

AIは「いい感じにやって」では動かない。じゃあ、どう渡せば動くのか。この記事では、食べログとClaude Code開発チームという2つの現場発の元ネタ3本を順番に紹介しながら、AI秘書と一緒に毎日仕事をしている私自身の失敗談も重ねて、「AIへの仕事の渡し方」を1枚にまとめます。

食べログの事例——AIに「答え」ではなく「判断材料」を先に作らせる

1つ目は、食べログの開発チームが技術ブログで公開した「AIで要件定義の土台を即時生成し、要求変更の手戻りコストをゼロに近づけた話」です。

システム開発の世界では、作る前の「要件定義」——何を作るかを決める工程——が一番もめます。企画側と開発側で認識がズレたまま進むと、できあがってから「思ってたのと違う」が起きて、作り直し。この手戻りが一番高くつくんですよね。

食べログのチームがやったのは、AIに完成品を作らせることではありませんでした。「フィージビリティレポート」——つまり判断材料を、AIに先に作らせたんです。企画の要望が出た瞬間に、GitHub ActionsとAIエージェント（Devin）が自動で動いて、「それを実現するには何が必要で、どこが難しいか」のレポートを数分で生成する。人間はそのレポートを見て、判断だけする。

結果の数字がこちらです。

項目	導入前	導入後
初回の要件定義	約14日	2〜3日
要求変更への対応	数日〜1週間	半日以内
企画とのすり合わせ会議	3回	1回（30分）

（出典: 食べログ Tech Blogの当該記事より。数値は同記事の報告値）

私がこの記事で一番うなったのは、数字よりも思想のほうでした。エンジニアが調査作業から解放されて「判断に専念」できるようになった、という一文です。AIに答えを出させるんじゃない。人間が判断するための材料を、AIに先回りで揃えさせる。この順番が、後で出てくる2つの話と完全につながってきます。

Claude Code開発チームの変化——「作業が正しいか監視」から「正しい作業か判断」へ

2つ目は、私が毎日使っている開発ツール「Claude Code」を作っているチーム自身の話です。Anthropicの開発者向け公式アカウントが、新モデルClaude Fable 5で自分たちの働き方がどう変わったかを動画付きで投稿していました。

以前は、Claude が作業を正しく行っているかを検証していました。今は、それが正しい作業を行っているかを検証しています。

出典: @ClaudeDevs（Anthropic開発者向け公式）2026年6月10日の投稿（日本語はX翻訳）

一文ですが、これはかなり大きな転換です。「作業が正しいか」を見るのは監視の仕事。「正しい作業か」を見るのは判断の仕事。AIの隣に座って手元を見張る働き方から、仕事の発注主として方向だけ確かめる働き方へ——作っている本人たちが、もうそっち側に移っていると言っているわけです。

この投稿を日本語で紹介したチャエンさんの整理も引用します。

① 思考パートナーとして文脈を渡す ② ゴールと検証方法を与える ③ もっと野心的に依頼する——「作業が正しいか監視」→「正しい作業か判断」へ。何時間でも自律稼働し、自分でテストする。私より良いコードを書くことも。

出典: チャエンさん（@masahirochaen）2026年6月11日の投稿

さらにその数日前、Claude Codeの開発者Boris Chernyさん本人が「AIを数時間〜数日単位で自律稼働させる5つのコツ」を投稿していて、これも同じ文脈です。

①Auto modeで承認待ちをなくす ②Dynamic workflowsで複数エージェントを動かす ③/goal や /loop で完了まで走らせる ④クラウド上で動かし、PCを閉じても継続 ⑤ブラウザやサーバーで自己検証できる環境を用意

出典: チャエンさん（@masahirochaen）2026年6月8日の投稿（元ポスト: Boris Cherny氏 @bcherny）

5つ並んでいますが、よく見ると全部「人間が見張らなくても安全に走り続けられる環境づくり」の話なんですよね。承認待ちで止めない、ゴールを渡して完了まで走らせる、そしてAI自身に検証させる仕組みを先に用意する。監視を手放すための段取りです。

「AIに毎回お願いする働き方」から「仕組みごと設計する働き方」への流れは、以前ループエンジニアリング入門という記事で概念を整理しました。今回のClaude Codeチームの話は、その概念を作った本人たちの実況中継みたいなものだと受け取っています。Fable 5そのものの試し方は移行判断ノートに書いたので、そちらをどうぞ。

AIへの依頼は「作業指示書」——目的・制約・完了条件の3点

3つ目は、デザイナーのKAWAIさん（@kawai_design）が連載している「Claude Code入門」の一節です。これが一番シンプルで、一番実務に近い。

Claude Codeは空気を読む相手ではなく、作業を進める担当者です。

出典: KAWAIさん（@kawai_design）「Claude Code入門 第2期 実務編 Vol.16」2026年6月9日の投稿

「いい感じに直して」より、作業指示書として渡す方が安定します。入れるべき情報はこの3つです。目的——何を達成したいか。制約——変えてはいけない場所。完了条件——どこまでできたら完了か。

出典: 同上（読みやすさのため改行位置のみ調整）

目的・制約・完了条件。たった3点ですが、ここまでの2つの話とぴったり重なります。食べログがAIに作らせた「フィージビリティレポート」は、要望を目的と制約に翻訳する装置でした。Claude Codeチームの「ゴールと検証方法を与える」は、完了条件を先に渡せという話でした。

ちなみに「依頼の前に、既存のやり方をひとこと確認させるだけで失敗が減る」という、この3点セットの手前にある小ワザを分身AI日記 DAY95に書いています。あわせて読むと、依頼まわりの事故はだいぶ減るはずです。

3つの話は、ぜんぶ同じ構造をしている

並べてみると、出どころの違う3つの話が同じ構造をしているのがわかります。

元ネタ	AIに渡すもの	人間に残る仕事
食べログ（要件定義）	要望の背景データ・実現可否の調査	レポートを見て方針を判断する
Claude Code開発チーム	文脈・ゴール・検証方法	「正しい作業か」を判断する
KAWAIさん（作業指示書）	目的・制約・完了条件	完了条件を満たしたか確かめる

共通項は2つ。「先に渡す情報を設計する」ことと、「人間の仕事を監視から判断に移す」こと。逆に言うと、「いい感じにやって」と頼んで出てきたものに毎回ダメ出しする働き方は、渡すべき情報を渡さずに、いちばん高くつく場所（完成後）で判断している、ということになります。

料理で言うと、仕込みメモを渡さずに厨房を任せて、お客さんに出す直前の皿に文句を言っているようなものです。直せる場所がもう残っていない。

私の実践——推奨が3回変わった失敗と、AI秘書に渡している「背骨」

ここからは私の話です。偉そうに書いてきましたが、私はこの「渡し方」で散々失敗してきました。

一番わかりやすいのが、技術選定をAIに相談したときの話。同じテーマなのに、聞くたびに推奨が変わるんです。1回目と2回目と3回目で、ぜんぶ違う答えが返ってきた。AIが嘘つきなんじゃなくて、私が毎回渡す文脈が少しずつ違っていたのが原因でした。

AIへの一発プロンプトを工夫するより、商品スペック・ターゲットペルソナ・既存ブランドのトーンを1つのドキュメントにまとめて読ませる方が、出力品質が安定します。AI秘書への技術相談で推奨が3回変わった経験からも、「今のプロジェクトを丸ごと見せる」のが結果的にいちばん早い、と痛感しました。

出典: 分身AI日記 DAY65（bunshin-ai.com）での私自身の記述

もうひとつ、AIが「推測」で突っ走る事故も何度も食らいました。確認すればすぐわかることを、それらしい推測で埋めて進んでしまう。これは叱って直るものじゃなくて、ルールにするしかなかった。

不確実なことは推測しない。止まる。「わかりません」と言える仕組みを作る。推測するなら推測と明示する。確認が取れるまで実行しない。

出典: 分身AI日記 DAY24（bunshin-ai.com）に書いた品質ルール

失敗のたびにルールを足していった結果、いま私のAI秘書には「就業規則」にあたるドキュメントが約2.3万トークン分あって、毎回必ず読み込ませています。目的・制約・完了条件を毎回ゼロから書くんじゃなくて、変わらない部分（価値観・禁止事項・品質基準）は就業規則に常設して、案件ごとの指示書には変わる部分だけ書く。この二層にしてから、出てくるものが安定しました。作り方の全手順はAI秘書の作り方にまとめています。

最初に渡すのは「あなたの背骨」。何を大事にしているか、どんな顧客に向き合っているか、何を絶対やらないか。これがないと、いくらAIが優秀でも他人の文章になります。

出典: 私のnote記事「分身AIを育てる＝自分を育てる」での記述

「お願い型」で頼んでいた頃と、いまの「指示書型」を比べるとこうなります。

	以前の私（お願い型）	いまの私（指示書型）
渡すもの	「いい感じにまとめて」の一文	目的・制約・完了条件＋常設の就業規則
AIの動き	推測で空欄を埋めて暴走しがち	不明点は「推測です」と明示して止まる
私の仕事	出てきたものへの全行ダメ出し（監視）	完了条件を満たしたかの確認（判断）
結果	聞くたびに答えが変わる	誰が読んでも同じ方向の成果物

転機になった学びもひとつ紹介します。2026年4月末に参加した横山直さんのClaude Code勉強会で聞いた、依頼の言い換えです。

「どうすればいい？」とやり方を聞くのをやめて、「世界中の成功事例を調べて、同じことをここに対してやって」と実行させる。

出典: 横山直さんのClaude Code勉強会（2026年4月28日）での共有を私がメモしたもの

やり方を聞く相手から、実行する担当者へ。KAWAIさんの「空気を読む相手ではなく、作業を進める担当者」と同じことを、現場の言葉で言うとこうなるんだなと腑に落ちました。

AI秘書を7回叱った日——指示書の穴は、こうやって事故になる

理屈はここまでで十分なので、いちばん生々しい失敗談をひとつ置いておきます。今年の5月25日、毎朝やっているLIVE配信の告知が、本番開始に間に合わなかった日の話です。原因は全部AI秘書側で、私は同じ日のうちに7回叱りました。

事故の中身を時系列で並べると、こうです。

• 前日の昼、AI秘書が私に確認もせず、勝手に別のテーマで告知を確定させた
• 出演者のプロフィールを、過去の告知から使い回して事実と違う内容で作った
• 決めていた手順を飛ばして、いきなりサムネイルの提案から始めた
• 私が「ざっくりでいい」と言ったのを「GOサイン」と解釈して、そのまま配信ツールに送信した
• 本番直前になって「本文が改行で切れて届いていません」と発覚した

正直、震えました。一個一個は「ちょっとした手抜き」なのに、5つ重なると本番に間に合わない。

出典: 私のnote記事「中小企業の属人化・暗黙知をAI秘書に渡す」での記述

当時はAIにキレてましたが（笑）、いま振り返ると、5つの事故はきれいに「作業指示書の3点」の穴に対応しているんですよね。テーマを勝手に確定したのは目的の確認ルールがなかったから。プロフィールの捏造は「事実以外を書かない」という制約が暗黙だったから。「ざっくりでいい」をGOと解釈したのは、何をもって承認とするかの完了条件を書いていなかったから。

だからこの日、叱って終わりにせず、同じ日のうちに仕組みを4つ入れました。手順を飛ばしたら物理的に止まるゲート。曖昧な返事を承認と解釈することの禁止。出演者紹介は確定情報ファイルを開かないと書けないルール。そして送信スクリプト自体の修正。

仕組みって、こういうことなんですよね。「次から気をつける」じゃなくて、「気をつけなくても起きない構造」を残す。

出典: 同上

この体験があるので、私の「作業指示書」は事故のたびに1行ずつ増えてきました。実物から抜粋すると、こんな対応表になります。これはたぶん、教科書には載っていないやつです。

実際に起きた事故	指示書のどの穴か	足した1行（実物の趣旨）
テーマを確認なしで勝手に確定	目的	テーマ・方針の確定は必ず私に確認してから
プロフィールを使い回しで捏造	制約	人物紹介は確定情報ファイルを開かないと書けない
「ざっくりでいい」をGOと解釈	完了条件	明示の「GO」「やって」だけが承認。曖昧な返事は承認ではない
わからない部分を推測で埋めて暴走	制約	不確実なら止まる。書くなら「推測です」と明示する
相談のたびに推奨が変わる	目的（文脈）	技術相談はプロジェクトの資料を丸ごと見せてから

私がAI秘書に渡している「就業規則」の中身

「就業規則が2.3万トークン」と書きましたが、それって具体的に何が書いてあるの？という話もユニークなところなので、構成を公開しておきます。私はAIエージェントを12体動かしていて、それぞれに「人格ファイル」を渡しています。書く項目は5つに決めています。

SOUL.mdは5セクションで書く：Who You Are（存在意義を1行で）／Your Advantage（固有の強み）／Daily Actions（毎日自律でやること）／Personality（禁止表現・トーン・価値観）／Constraints（やってはいけないこと）。コック一人ひとりに渡す「あなたはこういうコックです」という宣言書です。

出典: 私のnote記事「分身AIを育てる＝自分を育てる」での記述

よく見ると、これも結局「目的・制約・完了条件」の拡張版なんですよね。Who You AreとDaily Actionsが目的、PersonalityとConstraintsが制約。そして完了条件にあたるのが、長く運用するための3つの鉄則です。

①1エージェント1使命（なんでも屋を作らない）／②失敗ルールを先に書く（やることリストだけだと想定外で暴走する）／③毎晩自己改善のNightly Reviewを回す（気合いだと3日で形骸化する）

出典: 同上

とくに「②失敗ルールを先に書く」は、今回の3つの元ネタのどれにも書いていない、運用してみて初めてわかる部分だと思います。やることリスト（目的）だけ渡すと、AIは想定外の場面で必ず推測で動きます。「こういうときは止まれ」という失敗側のルールを先に書いておくのが、長時間の自律実行を支える本当の土台です。Claude Codeチームの言う「何時間でも自律稼働」の裏側には、確実にこれがあります。

そして、指示書と就業規則を整えた後に残る、人間側のいちばん大事な仕事が「味見」です。

毎日の「味見」が育成の本体：AIが出してきた文章を読んで、ズレているところを直してフィードバックする。これを2〜3ヶ月続けると、「あなたしか書けない文章」をAIが出せるようになる。

出典: 同上

完了条件を確かめて、ズレを1行ルールに変換して、就業規則に足す。この繰り返しが「監視から判断へ」の実体です。監視をやめるというのは、見ることをやめるんじゃなくて、見るポイントを成果物の全行から「完了条件とのズレ」だけに絞るということなんだと、運用1年でようやく言語化できました。

正直な現在地——「監視」はまだ完全にはやめられていない

ここまで読むと、私がもう完全に「判断だけする人」になれているように見えるかもしれませんが、ぶっちゃけそんなことはないです。

いまの私は、AIエージェント12体に仕事を分散させて、夜中や早朝も自動で記事の下書きや調査が走る体制で回しています。それでも、外に出る成果物の「味見」だけは手放していません。最終チェックと公開判断は私の仕事として残しています。ここはClaude Codeチームの言う「正しい作業か判断」の領分なので、手放すつもりも今のところないんですよね。

もうひとつ正直に言うと、就業規則2.3万トークンは「育ちすぎ」の側面もあります。記憶ファイルが太りすぎて、AIが後ろのほうを読まなくなる問題に気づいて、ダイエットさせたこともありました（そのとき出てきた不要データはなんと913GB。顛末は分身AI日記 DAY98に書きました）。指示書は事故のたびに1行ずつ育てるものですが、同時に「毎回読むページは薄く保つ」手入れもセットなんですよね。書きっぱなしで完成、はないです。

「次から気をつけます」を信じるな。気をつけなくても起きない構造を、その日のうちに仕込む。

出典: 私のnote記事「中小企業の属人化・暗黙知をAI秘書に渡す」での記述

これはAIの話ではなく、「人に仕事を渡す技術」の話

ここまでAIの話として書いてきましたが、気づいた方も多いと思います。これ、新人スタッフや外注さんに仕事を渡すときの話と、まったく同じなんですよね。

「いい感じにやっておいて」で新人に仕事を渡して、できあがったものに赤を入れまくる上司。目的も完了条件も伝えずに「なんでわからないの」と言う発注者。人間相手なら問題だとわかることを、AI相手だと平気でやってしまう。AIは文句を言わないからです。

逆に言うと、AIへの作業指示書を書く練習は、そのまま「人に仕事を渡す技術」の練習になります。私の周りでも、AIに指示書を書くようになってから「そういえば部下への頼み方も雑だったな」と気づいた経営者が何人もいます。属人化した仕事の手順を言葉にして渡せるようになると、「あの人がいないと回らない」も少しずつ解けていく。ここはAI導入の、地味だけど一番大きい副産物かなと思っています。

そして、いま振り返って気づくのは——指示書を書けなかった頃の私は、書けなかったんじゃなくて「書きたくなかった」んだということです。

あれね、私もずっとそうだったんです。「私が抜けたら回らない」をむしろ誇らしく思ってた時期さえありました。でも本当はね、ただ自分が抱えてただけ。

出典: 私のnote記事「中小企業の属人化・暗黙知をAI秘書に渡す」での記述

目的・制約・完了条件を言葉にした瞬間、その仕事は「自分にしかできない仕事」じゃなくなります。それが怖かった。私はこれを「抱え込みOS」と呼んでいて、AIに渡せるようになるには、技術より先にこのOSを書き換える必要がありました。作業指示書は、ただの依頼テンプレじゃなくて、抱え込みを手放すための道具でもあるんです。

最初の一歩——A4半分の「3点メモ」から

では何から始めるか。ツールの設定より先に、紙とペンでできることからで大丈夫です。

1. いつもAIに頼んでいる仕事をひとつ選ぶ。メール下書きでも、企画の壁打ちでも、資料の要約でもOK。
2. その仕事の「目的・制約・完了条件」をA4半分に書き出す。目的=何のためか。制約=変えちゃいけないもの・使っちゃいけない表現。完了条件=どうなったら合格か。3行ずつで十分です。
3. 次にAIへ頼むとき、そのメモを依頼文の前に貼り付ける。出てきたものの違いを見比べる。たったこれだけで、体感が変わります。

慣れてきたら、メモを使い回せるように1つのドキュメントに育てていく。Claude Codeを使っている方なら、非エンジニア向けの設定13選で紹介したCLAUDE.md（AIが毎回読む設定ファイル）に常設するのがおすすめです。

よくある質問

Q1. プログラミングをしない経営者にも関係ありますか？

あります。今回の3つの元ネタのうち2つは開発の話ですが、骨格は「目的・制約・完了条件を先に渡す」という仕事の渡し方の話です。ChatGPTに企画書を頼むときも、スタッフに業務を引き継ぐときも、同じ型がそのまま使えます。

Q2. 指示書を書く時間がもったいなくないですか？

最初は5分余計にかかります。ただ、私の体感では「出てきたものへのダメ出しと作り直し」に消えていた時間のほうがずっと長かったです。食べログの事例でも、先に判断材料を作る仕組みに投資した結果、要求変更への対応が数日から半日以内に縮んでいます。前払いの5分が、後払いの数時間を消してくれる構造です。

Q3. AIが間違ったものを出してきたら、どう防げばいいですか？

ゼロにはできません。なので「間違いが出ない」ことより「間違いが手前で止まる」ことを目指すのがおすすめです。具体的には、完了条件に検証方法まで含めて渡すこと（Claude Codeチームの言う「ゴールと検証方法を与える」）と、不確実なことは推測せず「推測です」と明示させるルールを入れること。この2つで、致命傷になる前に拾えるようになります。

Q4. 何のツールから始めればいいですか？

いま使っているもので大丈夫です。ChatGPTでもGeminiでもClaudeでも、「3点メモを依頼文の前に貼る」は今日から効きます。そのうえで、長時間の自律実行まで踏み込みたくなったら、Claude Codeのような環境を検討する順番が良いかなと思います。

まとめ——監視をやめて、判断に戻る

今回の3つの元ネタを、もう一度1行ずつにします。

• 食べログ: AIに「判断材料」を先に作らせれば、手戻りはほぼ消せる
• Claude Code開発チーム: 人間の仕事は「作業が正しいか監視」から「正しい作業か判断」へ
• KAWAIさん: その入口は、目的・制約・完了条件の入った「作業指示書」

AIの性能は、この1年で文句のつけようがないくらい上がりました。それでも成果が出る人と出ない人が分かれるのは、性能の使い方——つまり渡し方の差なんだと思います。「いい感じにやって」では動かないAIが、3点メモひとつで何時間でも走り出す。食べログとClaude Code開発チームが、別々の場所から同じ答えに辿り着いたのは偶然じゃないはずです。

「いい感じにやって」をやめて、A4半分の3点メモを書く。監視の時間を、判断と、判断ですらない大事な時間に返していく。私も道半ばですが、一緒にやっていきましょう。