海外のAI活用の天才たちは、ここまでやっている。驚きの実例15選

AIを10〜15人、同時に働かせる。
新しい本を読む前に、「この本に、自分がまだ知らないことは書かれているか」をAIに判定させる。
旅行、誕生日、服薬、家族の予定を、24時間動くAI秘書に先回りして管理させる。
食事管理アプリに不満があれば、Apple Watchに話すだけで記録できる自分専用アプリを作る。
ここまで聞くと、「さすがに一部の天才だけの話では？」と思いますよね。
でも、海外のAI活用者を調べていくと、こうした使い方が次々と見つかりました。
しかも、彼らが特別なのは、秘密の「魔法のプロンプト」を知っているからではありません。
違いは、AIに一度質問して終わらないことです。

複数のAIを役割別に働かせる
自分のデータや、普段使っている仕事道具につなぐ
指示を待つだけでなく、AIが自分から動く仕組みを作る
失敗するたびに、次から守るルールへ変える
最終確認と責任だけは人間に戻す
つまり、彼らが作っているのは「良い回答」ではなく、AIが継続して働く仕組みなんです。
今回は、海外の本人発信、インタビュー、研究論文、公開された運用記録など30件以上を調査。
その中から、
普通ではなかなか思いつかない
実際の運用方法まで確認できる
日本の私たちも発想を応用できる
という3つの基準で、15件を厳選しました。
ただし、先に大切なこともお伝えしておきます。
この記事には、本人が継続的に使っている事例だけでなく、企業の実装例、研究チームのプロトタイプ、公開デモ、提案されたワークフローも含まれます。
作業時間や生産性などの成果数値についても、第三者による検証を確認できなかったものは、本人または企業の自己申告として区別しました。
私自身が15の方法を使って効果を確かめたレビューではありません。
2026年7月24日時点で確認できた公開情報を基にした調査記事です。
その前提で読んでいただいても、たぶん何度か「AIって、そこまでやらせられるのか」と驚くはずです。

最初に真似しやすい3つ

15件とも面白いのですが、今日から比較的真似しやすいものを先に挙げると、この3つです。

資料をAIに読ませ、移動中に聞ける会話形式へ変える
1つのAIに作らせ、別のAIにレビューさせる
毎週繰り返している仕事を、実行・確認・改善まで一つの流れにする
これだけでも、AIは「質問すると答えてくれる相手」から、「仕事を一緒に進める相手」へ変わり始めます。
なお、顧客情報、社内情報、健康情報、家族の情報をAIへ接続するときは、保存先、アクセス権限、利用規約を必ず確認してください。便利さと安全性はセットで考える必要があります。

第1章　AIを「部下」のように動かす天才たち

1．Claude Codeの開発者は、10〜15人のAIを同時に働かせる

Claude Codeを開発したBoris Chernyは、1つのAIと会話しながら仕事を進めているわけではありません。
ターミナルでは、5つのClaudeを同時に起動します。
タブには1〜5の番号を付け、それぞれに別の仕事を渡す。入力や確認が必要になったときだけ、パソコンから通知が届くようにしています。
さらに、Web上でも5〜10のClaudeを並列で稼働させています。
ローカルで始めた仕事をWebへ引き継ぎ、外出中にはスマートフォンから新しい仕事を開始することもあるそうです。
つまり、多いときには10〜15のAIが、それぞれ別の仕事を進めている。その間、人間はAIの返答をじっと待つのではなく、各セッションの間を巡回するんです。
しかも、ただ大量に起動しているわけではありません。
Borisは、多くのセッションをPlan Modeから始めます。
最初にAIへ計画を作らせ、その計画に問題がなければ実装へ進ませる。
完成後は、テスト、ブラウザ操作、画面確認など、AI自身が結果を検証できる手段も与えます。
Claudeが同じ間違いを繰り返さないように、チームで共有する指示ファイルも持っています。
AIが間違えたら、人間がその場で直して終わりではありません。
「今後はこの条件を確認する」
「この書き方は禁止する」
といったルールをファイルへ追加します。コードレビューをしながら、そのルール自体を更新することもあります。
さらに、運用には次のような工夫も組み込まれています。

繰り返す作業は専用コマンドにする
調査や検証は別のAIに分担させる
コード整形は作業後に自動実行する
許可確認を減らす場合は、サンドボックス内に限定する
AIが「完成した」と言っても、テスト結果で判断する
では、何がそれほど天才的なのでしょうか。
一般的なAI活用では、「どうすれば一度で良い回答を出せるか」を考えますよね。
でも、Borisが最適化しているのは、1回の回答の速さではありません。
AIの処理待ち時間を、人間の待ち時間にしないことです。
1人のAIが処理に20分かかるなら、その20分を待たない。その間に別のAIへ次の仕事を渡します。
こうなると、人間の役割は作業者ではありません。
計画を決め、仕事を割り振り、途中で問題がないかを見て、最後の結果を確認する監督者です。
もちろん、最初から15体を動かす必要はありません。
たとえば「情報収集」と「下書き作成」を2つのAIへ分け、同時に進める。これだけでも考え方は同じです。
ポイントは、1つの長いチャットへすべてを詰め込まないこと。
仕事を分け、AIごとに「何ができたら完成なのか」を明確にするところから始められます。
出典：Boris Chernyの投稿

2．MicrosoftのCEOは、少なくとも10のAIエージェントを使い分ける

Microsoft CEOのSatya Nadellaは、Copilotの中に少なくとも10のエージェントがあり、異なる仕事について、それぞれへ問い合わせていると話しています。
ここで重要なのは、10体のAIを本人がゼロから開発したという意味ではないことです。
Copilot内の複数のエージェントを、用途に応じて使い分けているという話です。
その使い方の一つが、インタビュー前の準備でした。
Nadellaはインタビューへ備えるため、Copilotに関連資料を集めるよう依頼しました。
対象には、Microsoftの量子技術に関する2本のNature論文や、ゲーム生成モデルについての情報が含まれていました。
普通なら、集めた資料を要約させて読むところですよね。
ところがNadellaは、その資料を「2人が会話するポッドキャスト形式」へ変換させました。
読むための資料を、移動中にも聞ける予習番組へ変えたんです。完成した音声は、チームにも共有しています。
顧客との会議前には、CRMとMicrosoft Graphから必要な情報を集め、会議前に把握しておくべき内容を一つの資料へまとめさせています。
この使い方が面白いのは、単に文章を短くしているわけではないところです。
AIで時間を短縮しようとすると、多くの人は「要約して」と頼みます。
でもNadellaは、内容だけでなく情報の受け取り方まで変えているんです。
長い文章を読む時間がないなら、短くするだけではなく、音声番組にして移動時間へ移す。
情報が複数の場所に散らばっているなら、自分で探し回るのではなく、次の会議で使う資料として再構成させる。
要するに、これは単なる要約ではありません。
その情報を、次に行う仕事で使える形へ変換する作業です。
私たちが真似するなら、「この資料を要約して」で終わらせず、次の行動まで含めて依頼できます。

明日の打ち合わせで使う質問リストにする
移動中に聞ける2人の会話形式にする
上司へ3分で説明する台本にする
会議前に確認すべきリスクだけを並べる
AIを使うときは、「何を知りたいか」だけでなく、「どの場面で使うのか」まで渡す。これだけで、出力の価値はかなり変わります。
出典：Satya Nadellaのインタビュー

3．1日で27のAIセッションを動かし、コードを1行も手書きしない

Apache Airflowの開発に関わるKaxil Naikは、「4カ月間、コードを1行も手書きしていない」と明かしています。
それだけ聞くと、仕事をしていないようにも聞こえますよね。
実際は逆です。本人の説明では、以前より多くの仕事を進めているといいます。
2026年3月20日、Kaxilは6つの開発プロジェクトで、27のClaude Codeセッションを動かしました。
その日の仕事には、次のようなものが含まれていました。

15件のコードレビュー
本番障害を基に、障害調査用のAIスキルを作成
Slack検索用スキルの改善
Pythonで書かれた機能をGoへ移植
UIの不具合を発見し、その日のうちに修正・統合
プレゼン資料の準備
Google Docsの確認と執筆
12のSlackチャンネルで、50件以上のメッセージに対応
これだけの仕事をしながら、本人はエディタへコードを1行も入力しなかったそうです。
数カ月で150件以上のPRにも関わったと説明しています。
では、AIへ仕事を丸投げしているのでしょうか。
そうではありません。
Kaxilは、仕事ごとの手順を「スキル」として保存しています。
コードレビュー
障害調査
会議メモ
1日のまとめ
ブログ執筆
単に「レビューしてください」と頼むのではありません。
どこを見るのか、どの問題を重大と判断するのか、どの形式で報告するのかまで記録します。
つまり、AIへ作業を渡しているというより、自分の判断方法を、何度でも使える手順へ変えているんです。
作成と確認に異なるモデルを使うこともあります。Claudeが書いたものをGPTにレビューさせたり、その逆にしたりします。同じAIへ「自分の間違いを見つけて」と頼むより、別のモデルから違う視点を入れるためです。
AIが機能を作った後も、そこで終わりません。

開発環境を起動する
自動テストを実行する
画面を操作する
スクリーンショットや動画を撮る
人間が最終確認する
ここまでを一つの仕事として扱います。
そして、特に驚いたのが、障害が起きた後の処理です。
ある本番障害では、原因の特定に3日かかりました。
その後、クエリを1万5000倍高速化する修正につながったと本人は報告しています。
普通なら、修正してチケットを閉じますよね。
Kaxilは、その失敗パターンをAIの知識へ追加しました。次に似た変更が来たとき、AIが問題を事前に検知できるようにしたんです。
障害が一つ起きるたびに、同じ障害を防ぐ仕組みが一つ増える。
これが、AIで作業を速くするだけの使い方との決定的な違いです。
なお、PR数、1万5000倍という速度改善、生産性については、本人による報告です。
出典：Kaxil Naikの詳細記事

4．AIの働きを「1ドルあたりの成果」で評価する

「ClaudeとGPT、結局どちらが仕事で優秀なのか」
気になりますよね。
多くの人は、SNSの評判や使った印象で判断します。
でもMesaのBen Warrenたちは、それを実際の仕事のデータで測ろうとしました。
彼らが作った「Agent Blame」は、AIがファイルを編集した瞬間に、次の情報を記録します。

使用したAIツール
使用したモデル
追加された行
後から文章の雰囲気を見て、「これはAIっぽい」と推測する検出器ではありません。AIがファイルを編集した時点で情報を取得し、その行が実際にGitへ保存されたかを照合します。
最終的に一致した行には、使われたモデルや信頼度などの情報が残ります。
一方、人間が大きく書き換えた行や、記録用の仕組みを通さず追加された変更は、AI由来として追跡されない場合があります。
「それでは全部を追跡できないのでは？」と思うかもしれません。
そのとおりです。ただし、これは誤って人間のコードをAI作と判定しないための、精度を優先した設計でもあります。
レビュー画面では、AIによる編集として記録できた行に印が付きます。そこで担当者は、
重要な認証処理をAIが書いていないか
AIが生成した複雑な処理を、人間が十分に確認したか
特定のモデルが、同じ種類のミスを繰り返していないか
を確認できます。
さらに、モデル別、ツール別、担当者別に、AIによる編集の割合も追跡できます。
そこから分析できるのは、たとえば次のようなことです。
1ドルあたり何行が採用されたか
どのAIが自社の開発環境に合うか
AIが書いたコードとバグに関係があるか
担当者によってAIの成果がどう変わるか
AIを導入した会社では、「社員がAIを何回使ったか」を測りがちです。
でも、使用回数は成果ではありません。
Agent Blameが見ようとしているのは、AIが最終成果物へ、実際に何を残したかです。
同社は、コード生産量が2.4倍になり、レビューが約50％速くなったと報告しています。ただし、これは同社による自己申告であり、第三者が再検証した数字ではありません。
それでも、この考え方には大きな価値があります。
AIを「何となく便利」ではなく、本当にチームメンバーとして使うなら、人間と同じように成果、費用、品質を測る必要がある。AIを雰囲気で評価する状態から抜けようとしている点が、天才的なんです。
出典：Agent Blameの技術解説
 出典：Ben Warrenの投稿

5．旅行、誕生日、服薬まで管理する「家族専用AI秘書」

Omar Shahineが作った「Lobster」は、家族のために24時間動くAI秘書です。
専用のMac、Apple ID、メールアドレスを持ち、家族はiMessageで話しかけられます。
これだけでも十分すごいのですが、単に質問へ答える家庭用チャットボットではありません。
約25本の定期処理が、家族が寝ている間も動いています。
夜になると、Lobsterはその日の活動を記録します。
Obsidianへ日記を作り、複数のAIが「今日何をしたか」「何に失敗したか」「何が残っているか」を報告。それを一つの記録へまとめます。
深夜には、その日の情報から重要なものを長期記憶へ移します。重要度の低い情報は残し続けません。
人間が眠っている間に記憶を整理する仕組みを参考にした、「Memory Dreaming」と呼ばれる処理です。
そして毎朝、LobsterはOmarへ一つだけ質問します。
一般的な質問ではありません。過去の会話や記録を読み、情報が途中で切れている箇所を探します。
たとえば、「娘がステンドグラスに興味を持っている」と記録されているのに、なぜ始めたのかが分からない。すると、そこを質問します。
Omarが答えると、翌日の処理で適切な記憶ファイルへ保存されます。
1日1問なので、答える負担は小さい。でも数週間続けば、最初の面談では出てこない生活習慣、家族関係、過去の経験まで少しずつ蓄積されます。
読まなかった記事の処理も面白いです。
保存したまま読まなかった記事は、夜中に音声へ変換されます。
記事ごとに音声とカバー画像を作り、非公開のSpotify番組として配信。翌朝には、通勤や移動中に聞ける状態になっています。
Xで保存した投稿は別の処理が回収し、重複を除いて日別に整理します。
ここで興味深いのは、何でも生成AIへ任せていないことです。
X投稿の取得や重複除去など、答えが決まっている処理は通常のプログラムで行う。内容の関連付けや振り返りなど、判断が必要な部分だけをAIへ任せます。
さらにLobsterは、家族の予定にも先回りします。

夜8時以降の会議を夕方に知らせる
翌朝の早い会議を前夜に知らせる
誕生日カードを作り、7日前にも通知する
週末の家族予定をグループチャットへ送る
平日の服薬を確認し、返事がなければ再通知する
旅程情報から、家族の滞在都市・国・タイムゾーンを1日2回更新する
しばらく会っていない友人を月に一度振り返る
なお、GPSで家族を常時追跡しているわけではありません。登録された旅行日程を基に、現在どの都市やタイムゾーンにいる可能性が高いかを共有情報へ反映しています。
「何か忘れていない？」と人間が聞く前に動くわけです。
当初3体だったAIは、Microsoftの取材時点で9体の常時稼働エージェントへ増えていました。
ただし、全員へ同じ権限を与えているわけではありません。
本人とのDMでは広い権限を持つ。家族とのDMでは共有予定などに限定する。グループチャットでは、さらに操作できる範囲を狭める。
AIを便利にするほど、誰の指示で、何を操作できるのかを厳密にする。
ここまで含めて設計されている点が、単なる面白い個人開発とは違います。
出典：Lobsterの全ワークフロー
 出典：具体的な利用例
 出典：Microsoftによる紹介

第2章　欲しい道具を、その場で作る天才たち

6．Apple Watchに話すだけの食事記録アプリを作る

起業家のAndrew Warnerは、過去に食べたものを記録することで、約20ポンドの減量に成功したと話しています。
ところが、もう一度記録を始めようとしても続きませんでした。
理由は、知識がなかったからではありません。
食べるたびにスマートフォンを開き、アプリから食品を探して入力する。その作業が面倒だったからです。
「記録すればいい」と分かっていても、入力に手間がかかると続かない。あなたにも、似た経験があるかもしれません。
Andrewが本当に欲しかった機能は、とても単純でした。
Apple Watchへ、食べたものを話す。
すると、食品とカロリーがNotionへ記録される。
既存の食事管理アプリを探しても、思いどおりのものは見つかりませんでした。
そこでClaude Codeへ希望を説明し、自分専用のソフトウェアを作らせたんです。
完成後は、食べるたびに腕時計へ話しかけるだけで、記録できるようになりました。
さらに重要なのが、データの保存先です。
一般的な食事管理アプリでは、記録したデータがアプリの中へ閉じ込められることがあります。でもAndrewのデータは、自分のNotionへ入ります。
そのため、自分が本当に知りたい切り口で分析できます。

1週間に、どれくらいビールを飲んだか
食事と間食の比率
朝早く食べ始めた日と、遅く食べ始めた日の違い
間食が連続する時間帯
摂取カロリーの変化
今後はカレンダーともつなぎ、「誰と会った日」「どのような予定があった日」に飲酒や間食が増えるのかを調べる構想も示しています。
ただし、これは現在すでに使っている機能ではなく、本人が挙げた今後の改善案です。
この事例の天才的なところは、既存アプリに自分の行動を合わせなかったことです。
Andrewは逆に、自分が続けられる行動へソフトウェアを合わせました。
これまでは、アプリを作るなら多くの人に売れる必要がありました。でもAI時代には、「一人の小さな不便だけを解決するソフトウェア」も作れます。
市場規模が小さすぎて、企業は作らない。それでも本人が毎日助かるなら、作る価値は十分にあるんです。
なお、約20ポンドという減量幅は、本人による報告です。食事やカロリー情報を健康上の判断へ利用する場合は、AIの推定だけに頼らないよう注意が必要です。
出典：Andrew Warnerの投稿

7．SEOの調査、執筆、順位確認を一つのループにする

Mike Futiaが作ったのは、文章を自動生成するだけのSEOエージェントではありません。
SEOで本当に時間がかかるのは、記事を書く部分だけではないからです。
何を書くべきかを探す。競合を調べる。記事を公開する。その後の順位を確認し、次の改善へつなげる。
ここまで全部やって、ようやく一つのサイクルになります。
MikeのAIは、まずGoogle Search Consoleから、現在5〜20位にいるキーワードを抽出します。
まったく検索結果へ出ていないキーワードではありません。すでに表示はされていて、改善すれば上位を狙える可能性がある「ギャップゾーン」です。
そして、キーワードごとに具体的な推奨アクションを整理します。
次に使うのがApifyです。現在上位にいる競合ページを取得し、次の内容を調べます。

誰が自社より上位にいるのか
なぜ、そのページが上位にいると考えられるのか
各キーワードで、何を修正すればよいのか
本人の投稿で確認できるのは、「キーワードごとの具体的な推奨アクション」と「競合に勝つための修正点」を出すところまでです。
「既存記事を改善する」「商品ページを修正する」といった具体的な分類方法は、運用する人が自社に合わせて設計する部分になります。
さらに、最初に一度だけ、AIがブランドについて取材します。
ブランド、顧客、商品の特徴、競合との違い、文章のトーンなどを質問し、その回答をブランド情報として保存します。
以後の記事では、毎回同じ説明をしなくても、その情報を前提に文章を作れます。
この取材がないと、どうなるでしょうか。
AIは検索上位の記事をまとめ直したような、どの会社でも書ける文章を作りやすくなります。
検索上位を狙えても、「誰が書いても同じ記事」になってしまうんです。
そして、公開後も終わりではありません。
毎週順位を確認し、何が機能したのかを、次の企画や記事へ戻します。
調査→競合分析→執筆→順位確認→改善
この流れを一つの循環にしている。ここが、単発のAIライティングとの大きな違いです。
AIへ「SEO記事を書いて」と一度頼むだけでは、書いた後の結果が次の仕事へ戻ってきません。Mikeの仕組みでは、現実の順位がAIの次の判断材料になります。
なお、「月額200ドルのAhrefsを置き換える」という表現は、本人による宣伝的な主張です。機能や順位改善効果が、第三者によって比較検証されたわけではありません。
出典：Mike Futiaの投稿

8．30秒の画面録画を、アプリ実装の指示へ変える

アプリを作るには、通常、画面構成や機能を文章で説明する必要があります。
でも、使いやすさや操作感って、言葉にしにくいですよね。
「このボタンを押すと、画面がこう切り替わる。ここが動いて、次にこの情報が表示される」
これを漏れなく文章にするのは、かなり大変です。
Agenteersが公開したのは、参考アプリを操作している様子をAIへ見せ、試作につなげるデモでした。
やり方は、驚くほど単純です。
まず、参考にしたいアプリを30秒ほど操作し、画面録画します。
その映像を、指定したプロンプトとともにGeminiへ渡します。
Geminiが出した内容をVibeCodeへ貼り付け、Claude Opus 4.6にアプリを組み立てさせます。
ただし、ここは誤解しないでください。
本人の投稿で確認できるのは、この一連のデモまでです。Geminiが完全な仕様書を作れることや、元のアプリを正確に再現できることまで検証されたわけではありません。
では、この事例から何を持ち帰ればいいのでしょうか。
ポイントは、単にAIへコードを書かせる技ではありません。
言葉にしにくい操作を、動画でAIへ伝えるという発想です。
この考え方は、アプリ開発以外にも使えます。

Excelの集計作業を画面録画する
社内システムへの登録方法を録画する
デザインを修正する手順を見せる
毎月の請求処理を、操作しながら説明する
その動画をAIに読み取らせ、作業手順を文章にさせる。そこから、自動化できる部分を探したり、マニュアルを作ったりできます。
文章だけでは伝えにくい仕事ほど、「実際にやっているところを見せる」という入力方法が役立つわけです。
もちろん、既存アプリのデザイン、コード、文章、画像、商標を無断で複製してよいわけではありません。
この事例から持ち帰るべきなのは、「他社のアプリをコピーする方法」ではなく、実演そのものをAIへの入力に変える方法です。
出典：Agenteersの投稿

9．AIを「コミュニティの共同創業者」にする

0xDesignerは、Claude Codeをプログラミング以外の仕事にも使っています。
しかも、本人が公開した使い方は一つや二つではありません。
まず、AIが毎朝、自分専用の情報レポートを作ります。
SNSを確認し、

注目されている話題
自分の分野に関係する変化
翌日作れそうなコンテンツ
参考になる投稿へのリンク
をまとめてメールで送ります。
一般的なニュースを並べるのではありません。本人の活動や関心に合わせたレポートです。
買い物の方法も少し変わっています。
「ランニングシューズを探して」と頼んで終わりではありません。AIが、
何のために走るのか
どれくらいの距離を走るのか
どのような運動をしているのか
商品選びで何を重視するのか
を取材します。
その条件に合う商品を探し、カートへ入れるところまで進めます。最終購入だけは本人が確認します。
人間が最初から細かい検索条件を考えるのではなく、目的を理解したAIが検索条件を作るんです。
筋トレと食事の管理にもAIを使っています。
AIが目標を聞き、トレーニング計画と食事計画を作ります。ジムでは、重量と回数を会話で記録。食事を伝えると、その日に残っている摂取カロリーを更新します。
計画を作るAIと記録するAIが別々ではないため、実際の行動に応じて次の判断を変えられます。
そして、特に規模が大きいのが、コミュニティ運営です。
運営するコミュニティでは、AIが次のような仕事に関わります。
毎日の活動レポートを作る
メンバーの権限を管理する
支払い状況に応じてアクセスを制御する
メール送信用の仕組みを作る
入会希望者について判断材料を整理する
Discord上の発言から、各メンバーをどう支援できるか考える
本人がClaudeを「コミュニティの共同創業者」と呼ぶ理由が分かりますよね。
顧客インタビューも、記録を作って終わりではありません。
ユーザーインタビューをGranolaで録音・文字起こしし、すべての記録をフォルダへ入れます。AIが、共通する悩み、何度も出てくる言葉、改善要望を抽出します。
そして次にデザインを考えるときも、同じフォルダを読み込ませます。
調査結果を報告書にして眠らせず、次の制作工程へそのままつなげるんです。
この5つの使い方には、共通点があります。
AIが単独で動いていません。
SNS、メール、ブラウザ、GitHub、Discord、インタビュー記録など、仕事に必要な場所とつながっています。
AIそのものを賢くするより、AIが仕事に必要な情報へ到達できるようにする。
ここが、チャット画面で相談するだけの使い方との大きな差です。
出典：0xDesignerの投稿

10．研究チームは、AIを投資家、メンター、評価者に分けた

Wharton教授のEthan Mollickらが開発した「PitchQuest」は、起業家が投資家へのプレゼンを練習するための教育用プロトタイプです。
これは、Mollick本人が日常的に使っているAIルーティンではありません。
複数のAIで練習環境を作る可能性を示すため、研究チームが制作したものです。
システムの中では、複数のAIが異なる役割を持ちます。

投資家などの登場人物として応答するAI
学習者を支援するメンター役のAI
教員向けに学習状況を評価するAI
ユーザーとのやり取りに応じて展開が変わる、適応型のシミュレーションとして設計されています。
一つのAIへ「私のプレゼンを評価してください」と頼むだけの仕組みではありません。
AIにプレゼンのコツを聞けば、一般的なアドバイスはすぐにもらえます。
でも本番で難しいのは、知識を知っていることではありません。
予想外の質問を受けた瞬間に考え、短く答えることです。
PitchQuestでは、失敗しても問題のない環境で、その経験を繰り返せます。
この考え方は、次のような練習にも応用できそうです。
採用面接
営業商談
価格交渉
クレーム対応
記者会見
上司への提案
ただし、これらはPitchQuestで効果が検証された用途ではありません。仕組みから考えられる、本記事上の応用例です。
この事例の天才的なところは、AIを先生として使うだけではなく、練習する世界そのものをAIで作っていることです。
知識を受け取るだけではなく、本番に近い判断を何度も経験できます。
研究チーム自身も、教育効果については、さらに厳密な検証が必要だと認めています。
それでも、一人ひとりの回答に応じて変化する練習環境をAIで作れる可能性は大きいですよね。
出典：研究論文「AI Agents and Education」

第3章　知識と判断をAIに移す天才たち

11．本を読む前に「自分が知らないことがあるか」を判定させる

Mr. Buzzoniが「Book Filter」と呼んで紹介したのは、本を速く読む方法ではありません。
そもそも、その本を読む必要があるのかを判断する使い方です。
なお、「Book Filter」はNotebookLMの公式機能名ではありません。本人が紹介した活用アイデアです。
やり方は、まず、これまでObsidianへ蓄積してきた自分の知識をNotebookLMに入れます。
次に、確認したい本の内容を、権利上問題のない方法で資料として追加します。
そして、こう質問します。

この本に、私がまだ知らないことはありますか？
新しい内容が少なければ、最初から最後まで読む優先度を下げる。
まだ知らない部分が見つかれば、該当箇所を重点的に確認する。
普通は、AIへ「この本を要約して」と頼みますよね。でも、全員に同じ要約が役立つわけではありません。
初心者にとって大切な説明でも、その分野に詳しい人にとっては、すでに知っている内容かもしれません。
この使い方が探すのは、本の一般的な重要部分ではありません。
自分の知識と、本の内容の差分です。
学習量が増えるほど、すでに知っている説明を何度も読む時間も増えます。その重複部分をAIに探させようという発想なんです。
本人は、YouTube動画をNotebookLMへ送る外部拡張機能を使い、チャンネル内の複数動画をまとめて取り込む方法も紹介しています。
複数の動画で何度も繰り返される説明を整理し、共通する主張や、新しい部分を抽出する。
さらに資料を2人の会話形式のAudio Overviewへ変換し、歩いている時間や移動時間に聞く使い方も挙げています。
ただし、便利だからといって、AIの判定をそのまま信じるのは危険です。
AIが「新しい内容はない」と答えても、表現のニュアンス、事例、反論、著者独自の論理まで正確に比較できているとは限りません。
本を読むかどうかの最終判断を丸投げするのではなく、全文を読む前の優先順位付けや、読むべき章を探す補助として使う方が現実的です。
また、「100時間を10分に圧縮できる」といった数字は、本人の宣伝的な表現です。第三者によって検証された成果ではありません。
出典：Mr. Buzzoniの投稿

12．記事をフォルダへ入れるだけで、知識同士がつながる

J.B.が公開したのは、Claude CodeとObsidianを組み合わせた「第二の脳」の作り方です。
本人の投稿で確認できる流れは、とてもシンプルです。
記事をフォルダへ入れる。
Claude Codeが記事を読む。
Wikiページを作り、概念同士の関係を構築し、すでにある情報へ自動でリンクする。
一般的なAI要約では、記事Aの要約、記事Bの要約、記事Cの要約が別々に並びます。
後から「3つの記事に共通する考えは何か」を探したくなったら、もう一度すべてを読み直す必要があります。
ところが、J.B.が紹介した仕組みでは、新しい情報を既存のWikiへつなげます。
そのため、新しい記事が入るたびに、過去の情報との関係が増えていきます。
増えるのは、情報の量だけではありません。情報同士のつながりも増えるんです。
ここから先は、J.B.の投稿をそのまま再現したものではなく、この考え方を記事リサーチへ応用する場合の提案です。
たとえば、AIに関する記事を保存するとき、次の項目に分けて記録します。

登場した人物や企業
紹介されたAIツール
具体的な活用法
本人が報告した成果
注意点
元の出典
過去の記事と異なる主張
次の記事を入れたとき、同じ人物、ツール、概念のページへ追記させます。
これだけでも、「保存したのに二度と読まない資料」が、「次の企画で使える知識」へ変わります。
調べものをすると、資料はどんどん増えます。でも、保存するだけでは、使える知識になりません。新しい情報が入るたびに、過去の情報と結び付け直す必要があります。
そこをAIへ任せるという発想です。
なお、人物や企業ごとの分類、過去の主張との矛盾確認は、本記事で提案している応用方法です。J.B.の投稿で、そこまでの具体的な実装を確認できたわけではありません。
出典：J.B.の投稿

13．実在する専門家の判断基準を使い、3〜5体のAIに審査させる

Machinaが提案したのは、複数のAIに同じ原稿を読ませ、別々の角度から審査させる方法です。
これは、本人が継続的に使っている日常ルーティンとして公開したものではありません。「AIの出力を改善する方法」として紹介されたワークフローです。
「あなたは一流コピーライターです」とAIへ役割を与える方法は、よく見かけますよね。
でも、この方法は少し違います。根拠のない架空の専門家を演じさせるのではなく、実在する人物が公開してきた判断基準を抽出します。
まず、尊敬する人物の資料をNotebookLMへ入れます。

YouTubeチャンネル
ブログ
ニュースレター
ポッドキャスト
インタビュー
そこから、
フレームワーク
判断パターン
原則
を抽出し、「専門家カード」として整理します。
その資料をClaudeのプロジェクトや、AIが参照できる記憶へ追加します。
Claudeが最初の原稿を作った後は、3〜5体のAIが同時にレビューします。
1体目は、専門家Aの判断基準でレビューする
2体目は、専門家Bのフレームワークで弱点を探す
3体目は、ほかのAIが見落とした問題を探す
最後にClaudeがすべての指摘を読み、どの意見を採用するかを判断し、原稿を書き直します。
人間が目にするのは、複数の審査を通過した最終版です。
この方法を一般的な記事制作へ応用するなら、次のように役割を分けられます。
顧客の立場から、理解できない部分を探すAI
事実関係を確認するAI
論理の飛躍を探すAI
反対意見を出すAI
ほかのAIが見落とした問題を探すAI
ただし、これらはMachinaが固定役割として指定したものではありません。本記事で示す応用例です。目的に合わせて設計できます。
この使い方の面白いところは、答えの数を増やしているわけではないことです。
同じAIへ「もっと良くして」と繰り返しても、似た方向の修正が続きやすくなります。
そこで、最初から違う評価基準をぶつけます。
増やしているのは、答えではなく判断基準なんです。
この考え方は、原稿だけでなく、
商品企画
広告
デザイン
採用計画
事業戦略
プレゼン資料
にも応用できます。
ただし、いくら専門家の発信を大量に入れても、AIが本人と同じ判断をする保証はありません。
あくまで、公開情報から再構成した「その人の考え方を参考にするAI」です。本人の承認や監修を受けたものでない限り、「本人の意見」として扱ってはいけません。
また、本人の投稿にある「100倍」という表現も、測定された性能向上ではなく、宣伝上の表現として扱う必要があります。
出典：Machinaの投稿

14．Ray Dalioは、自分の「答え」ではなく判断基準をAIに移す

Bridgewater Associates創業者のRay Dalioは、「Digital Ray」という自分のAI版を育てています。
Dalioは、人生や仕事から学んだ判断基準を、長年「原則」として書き残してきました。
Digital Rayに使われているのは、

数千の原則
著書
インタビュー
過去の発言
などです。
目的は、本人の口調を表面的に真似させることではありません。過去の原則や発言を基に、「Dalioなら、どのように考えるか」を再現しようとしています。
でも、資料を大量に入れれば、自動的に本人らしいAIが完成するわけではありません。
生成された回答を、Dalio本人が「自分なら、本当にそう答えるか」と確認します。
長年一緒に働いてきたチームも、回答の検証や資料の整理へ参加しています。本人によると、この調整に1日およそ2時間を使っています。
AI分身を作ったからといって、すぐに本人の仕事が減るわけではないんです。
むしろ最初は、本人らしい回答へ近づけるために、多くの確認作業が必要になります。
では、そこまで時間を使う意味はどこにあるのでしょうか。
Digital Rayが本人と違う答えを出した場合、次のような可能性を調べられます。
AIが原則をうまく参照できていない
判断に必要な情報が入力されていない
原則同士の優先順位が曖昧
原則の文章だけでは、判断条件が伝わっていない
ただし、これはDalio本人が公開した原因一覧ではありません。Digital Rayの調整方法から考えられる、本記事上の解釈です。
それでも、AIの回答を直す作業が、自分の判断基準を言葉にし直す作業にもなり得ることは分かります。
多くの人は、AIへ正解を聞きます。
Dalioが目指しているのは、自分が正解を考えるときに使ってきた原則を、AIへ渡すことです。
単純なQ&A集ではありません。
過去の原則、著書、インタビューを基に、本人ならどのように考えるかを再現しようとしています。
AIへ知識を入れる次の段階は、情報量を増やすだけではないのかもしれません。
判断の条件、優先順位、例外まで記録する。そこまでできて初めて、「自分の考え方を支援するAI」に近づくんです。
出典：Ray Dalio本人の説明

15．20年分の発信から、声と映像を持つAI分身を作る

LinkedIn共同創業者のReid Hoffmanは、20年以上にわたる自身の発信を基に、「Reid AI」を作りました。
AI分身と聞くと、本人そっくりの顔や声を想像しますよね。
でも、最初に作ったのは見た目ではありません。知識の土台です。
Reid AIは、次のような資料を参照して回答します。

著書
講演
ポッドキャスト
インタビュー
過去の記事
公開された発言
Custom GPTが20年分の資料を基に回答を作ります。
その文章をElevenLabsが本人に近い声へ変えます。
Hour Oneが本人を再現した映像を作ります。
文章、音声、映像という複数のAIを組み合わせることで、話すデジタル分身にしているわけです。
Hoffmanは、本物の自分とReid AIの対談も行いました。
本物のReid Hoffmanが質問し、AI版が20年分の発信を基に答えます。
その後、自著『Superagency』のレビューもReid AIへ依頼しています。
著者本人の代わりに宣伝文を書かせるだけではありません。本人が過去に発信してきた内容を踏まえ、新しい本をどう評価するのかを試しています。
ここで大事なのは、顔と声だけを似せていないことです。
見た目だけ本人そっくりでも、中身が一般的なAIのままなら、本当の意味での分身とは言えません。
Reid AIでは、先に20年分の知識と発言を参照できる土台を作り、その後に音声と映像を与えています。
見た目をコピーする前に、「何を考えてきた人物なのか」を入れている。
ここが、単純なAIアバターとの違いです。
一方で、声と映像を持つAI分身には、大きな危険もあります。
本人が言っていない内容を話させる
古い考えを、現在の意見のように見せる
本人とAIの区別がつかなくなる
なりすましに利用される
本人の代わりに情報を届けられるからこそ、悪用されたときの影響も大きくなります。
AI分身を公開するなら、AIであることの表示、本人の承認、発言できる範囲、参照情報の更新日などを明確にする必要があります。
出典：Reid HoffmanとReid AIの対談記録
 出典：Reid AIによる著書レビュー

15件を調べて分かった、AI活用の天才に共通する7つのこと

ここまでの15件は、使っているツールも、目的も、規模も違います。
開発、会議準備、家族の予定、食事、SEO、学習、コミュニティ運営、知識管理、AI分身。
一見すると、まったく別の事例ですよね。
ところが、仕組みを分解してみると、驚くほど似た設計が使われていました。

1．プロンプトではなく「仕事の流れ」を渡す

海外の上級者は、調査だけ、執筆だけ、要約だけでAIの仕事を終わらせません。
入力、実行、確認、改善までをつなげています。
Mike FutiaのSEOは、記事を書いて終わりではなく、公開後の順位確認まで行い、その結果を次の記事へ戻します。
Kaxil Naikの開発では、AIが実装した後に、テスト、画面操作、スクリーンショットや動画による確認まで進みます。
Lobsterは、予定を調べるだけではありません。必要な時間になったら、本人や家族へ知らせます。
つまり、AIへの指示が単発の作業ではなく、循環になっているんです。
「メールを書いて」だけなら、AIの仕事は文章を出した瞬間に終わります。
でも、「過去のやり取りを確認する→下書きを作る→送信前に人間へ確認を求める→修正内容を次回のルールへ残す」まで渡せば、仕事の流れになります。
ここが、プロンプトの工夫と、AIを仕事へ組み込むことの違いです。
自分の仕事へ取り入れるなら、まず紙やメモに、いつもの手順を順番どおり書き出してみてください。
「何が起きたら始めるのか」
「最初に何を読むのか」
「途中で何を判断するのか」
「何ができたら完成なのか」
「失敗した場合は、誰へ確認するのか」
ここまで見えると、AIへ渡せる部分と、人間が残る部分を分けやすくなります。優れたプロンプトを一度で書こうとするより、仕事の全体像を見せた方が、AIは次に何をすればよいか理解しやすくなるんです。

2．1体の万能AIを作ろうとしない

調査するAI、作るAI、批判するAI、評価するAI。
海外の事例では、仕事を分け、複数のAIを同時に動かしています。
「全部できる天才AIを1体作ろう」とすると、指示が長くなり、何をもって完成とするのかも曖昧になります。
一方、役割を分ければ、それぞれの完成条件がはっきりします。

調査担当は、出典付きで事実を集めたら完了
執筆担当は、指定した読者向けに下書きを作ったら完了
事実確認担当は、根拠のない表現を指摘したら完了
最終担当は、複数の指摘を整理して書き直したら完了
Boris Chernyの10〜15セッションも、Machinaの3〜5体によるレビューも、Kaxil Naikの別モデルによる確認も、考え方は同じです。
一つの頭にすべてを詰め込まず、仕事の役割と責任を分ける。これは人間のチーム作りとよく似ています。
真似するときも、最初から大人数のAIチームを作る必要はありません。
まずは「作るAI」と「確認するAI」の2体で十分です。
たとえば、1体目に記事の下書きを作らせ、2体目には元資料だけを渡して、事実と異なる表現を探させます。最後に人間が、どの指摘を採用するかを決めます。
このとき、同じ依頼文を2体へ投げるのではなく、役割ごとに見る範囲を限定することが大切です。
調査担当へ文章の美しさまで求めない。文章担当へ最終的な事実保証まで丸投げしない。それぞれの仕事を小さくするほど、問題が起きた場所も見つけやすくなります。

3．自分のデータを持たせる

一般的な知識だけを持つAIからは、一般的な答えが返ってきます。
一方、今回の事例では、

食事の記録
顧客情報
過去の判断
会議資料
インタビュー記録
コミュニティの活動
家族の予定
著書や過去の発言
など、本人や組織に必要なデータをAIへ渡しています。
Andrew Warnerの食事管理が本人に合っているのは、自分のNotionへ記録が蓄積されるからです。
Satya Nadellaの会議準備が実務で使えるのは、CRMやMicrosoft Graphにある情報を、次の会議向けにまとめるからです。
Ray DalioやReid HoffmanのAI分身も、一般知識だけでは成立しません。本人が長年残してきた原則や発信が必要です。
必要な範囲で自分のデータを渡すことで、AIは「誰にでも当てはまる回答」から、「その人の状況に合った仕事」へ近づきます。
ただし、データを渡すほど、保存先、アクセス権限、削除方法の確認が大切になります。個人情報や機密情報を、便利だからという理由だけで無制限に渡してはいけません。
ここでのポイントは、最初からすべてのデータをつなげないことです。
記事作成を手伝わせるなら、まずは公開済みの記事と、公開しても問題のない文体ルールだけを渡す。会議準備なら、その会議に本当に必要な資料だけを渡す。
「あると便利そうだから」ではなく、「この仕事の判断に必要だから」という理由でデータを選びます。
誰がそのデータを読めるのか、AIが外部へ送信できるのか、利用をやめたとき削除できるのかも確認します。
自分専用のAIを作ることと、自分の情報を無制限に公開することは同じではありません。必要最小限のデータと権限から始める方が、安全に改善を続けられます。

4．正解ではなく、判断基準を記録する

「良い記事を書いて」
「コードをレビューして」
この頼み方では、AIは「良い」の基準を推測するしかありません。
海外の上級者がAIへ移しているのは、答えだけではなく、何を良いと考え、何を問題だと判断するのかという基準です。
「どの問題を重大と考えるのか」
「どの条件なら公開してよいのか」
「どのような表現は使わないのか」
「何を確認できたら完成なのか」
Kaxil Naikは、コードレビューや障害調査の判断方法をスキルとして残しています。
Ray Dalioは、数千の原則をDigital Rayの土台にしています。
Machinaのワークフローでは、実在する専門家のフレームワークや判断パターンを「専門家カード」にします。
AIへ移す価値が高いのは、完成済みの答えだけではありません。次の未知の問題にも使える判断基準なんです。
たとえば、記事の品質基準なら、

数値には確認できる出典を付ける
本人の発言と記事側の解釈を分ける
初心者でも分かる具体例を一つ入れる
読者が次に取る行動を明確にする
確認できない効果は断定しない
のように書けます。
この基準があれば、テーマが変わっても同じ考え方で確認できます。
さらに、基準同士がぶつかったときの優先順位も必要です。「面白さより正確さを優先する」「短さより、誤解を防ぐ説明を優先する」といった順番です。
答えだけを保存すると、似た問題にしか使えません。でも判断基準を保存すれば、まだ見たことのない仕事にも応用しやすくなります。

5．失敗を次回の仕組みに変える

AIが間違えたとき、その場で修正して終わっていませんか？
そのチャットでは直っても、新しいチャットを始めれば、また同じ間違いが起きるかもしれません。
海外の事例では、間違いを、

ルール
チェックリスト
禁止事項
テスト
再利用できるスキル
として残します。
Boris Chernyは、AIが繰り返した間違いを共有の指示ファイルへ追加します。
Kaxil Naikは、本番障害で見つかった失敗パターンをAIの知識へ加え、次に似た変更が来たときに検知できるようにしました。
一度起きた失敗が、次回からの防御になるわけです。
AIを長く使うほど成果が良くなる仕組みを作りたいなら、成功例だけではなく、失敗の履歴を残す必要があります。
実践するときは、「AIが間違えた」という曖昧な記録で終わらせない方が役立ちます。
何を入力したのか。どの出力が問題だったのか。本当は何を確認すべきだったのか。次回は、どの時点で止めればよいのか。
この4点を短く残します。
たとえばリンク切れを見逃したなら、「次は気をつける」ではなく、「公開前に全URLへアクセスし、開けないものを一覧化する」と、実行可能な確認手順へ変えます。
ルールを増やしすぎるとAIが読み切れなくなるため、似たルールはまとめ、不要になったものは見直します。
失敗を責める材料ではなく、次の仕事を安定させる設計材料として使う。そう考えると、AIの間違いも無駄になりません。

6．AIに任せる仕事と、通常の自動処理を分ける

何でもAIに考えさせればよいわけではありません。
Lobsterは、X投稿の取得や重複除去など、答えが決まっている処理を通常のプログラムで行います。
一方、内容の関連付けや、その日の振り返りなど、判断が必要な部分だけをAIへ任せます。
同じ入力から必ず同じ結果を出したい処理に生成AIを使うと、出力が揺れたり、余計な費用がかかったりします。
逆に、文章の意味を読み取る、複数の情報から関係を見つける、状況に合わせて優先順位を付けるといった仕事は、AIが得意です。
何でもAI化するのではなく、
確実に処理できる部分は通常の自動化へ、判断が必要な部分はAIへ。
この分け方が、仕組みを安定させます。
たとえば、毎朝9時にファイルを取得する処理や、同じ名前のデータを削除する処理は、決められたルールどおりに動く通常の自動化が向いています。
一方、そのファイルの内容を読み、「今日対応すべきものはどれか」「過去の事例と何が違うか」を判断する部分では、AIが役立ちます。
そして、送信や削除など影響の大きい操作は、人間の確認へ戻します。
つまり、

集める・並べる・重複を除く
↓
AIが意味を読み、分類・提案する
↓
人間が重要な行動を承認する
という分担です。
すべてをAIへ任せるより、処理ごとに最も安定した方法を選ぶ方が、費用も失敗も抑えやすくなります。

7．最後の責任は人間が持つ

購入、メール送信、コード公開、健康、家族情報。
今回の事例では、重要な行動ほど、人間の最終確認や細かな権限設定が残されています。
0xDesignerの買い物では、AIが商品をカートへ入れても、最終購入は本人が確認します。
Kaxil Naikの開発では、AIがテストや画面確認を行っても、最後は人間が確認します。
Lobsterは、本人とのDM、家族とのDM、グループチャットで、AIが操作できる範囲を変えています。
AIへ任せる範囲が広がるほど、「誰が止めるのか」「どの操作には承認が必要なのか」を先に決める必要があります。
AIに任せることと、AIを放置することは違います。
海外の上級者は、自動化を進めながら、最後の責任までAIへ渡してはいないんです。
判断するときは、「間違えた後に簡単に戻せるか」を考えると分かりやすくなります。
下書きを作る、情報を分類する、候補を並べるといった作業は、間違えても比較的戻しやすいものです。
一方、顧客へ送信する、契約する、決済する、公開する、削除するといった操作は、実行後の影響が大きくなります。
そのため、AIには下書きや候補作成まで任せても、実行ボタンは人間が押す。あるいは、金額や送信先など一定の条件を超えたときだけ、必ず承認を求めさせます。
自動化の完成度は、「人間を完全に消せたか」では決まりません。必要な場所へ人間の判断を残しながら、それ以外の負担をどれだけ減らせたかで考える方が現実的です。

私たちが真似するなら、最初の7日間でやること

ここまで読んで、「面白いけれど、自分には10体のAIも家族専用秘書も作れない」と感じた方もいるかもしれません。
大丈夫です。
いきなり大きな仕組みを作る必要はありません。最初は、毎週繰り返している面倒な仕事を一つ選ぶだけで十分です。

1日目：繰り返している仕事を一つ決める

資料作成、記事調査、会議準備、問い合わせ整理など、毎週似た手順で行っている仕事を一つ選びます。
最初から「会社全体をAI化する」のような大きなテーマを選ばないことがポイントです。
たとえば、

毎週月曜日に、複数の資料から報告書を作っている
記事を書く前に、同じサイトやSNSを調べている
会議前に、過去のメールと資料を探している
問い合わせを読み、担当者ごとに振り分けている
といった、開始条件と完成形が分かりやすい仕事を選びます。
選ぶ基準は3つです。

同じような手順を月に何度も繰り返している
必要な入力と完成形を説明できる
間違えても、公開や送信の前に人間が止められる
3つすべてに当てはまる仕事は、最初の実験に向いています。
反対に、毎回条件が大きく変わる仕事や、一度の間違いが契約・健康・お金へ直結する仕事は、最初の題材にしない方が安全です。
この日のゴールは、AIツールを選ぶことではありません。

毎週○曜日に、○○を読み、○○を作る仕事
という一文を作ることです。
たとえば、「毎週金曜日に、1週間分の問い合わせを読み、よくある質問と未解決事項をまとめる」と書ければ、次の日から具体的な手順を見せられます。
候補が複数ある場合は、「一番面倒な仕事」より、「一番手順を説明しやすい仕事」を選んでください。最初の成功体験を作りやすくなります。

2日目：実際の手順をAIに見せる

自分が普段どのように仕事をしているかを、AIへ伝えます。
文章で説明しにくければ、画面録画、過去の完成物、チェックリストを使えます。
「まずこの画面を開く」「この数字を確認する」「この条件なら別の表へ移す」と、実際の順番が分かる形にします。
ただし、画面録画には注意が必要です。
顧客名、メールアドレス、社内情報、個人情報、パスワードなどが映り込んでいないか、AIへ渡す前に確認してください。
見せるときは、うまくできた完成例だけでなく、途中で迷う場所も説明します。
「この条件ならAへ進む」
「数字が一致しないときは処理を止める」
「この項目だけは、過去の資料を確認してから決める」
こうした分岐に、その人の判断基準が隠れています。
可能なら、実際の作業を一度行いながら、声に出して考えていることを説明します。画面操作だけでは、なぜそのボタンを選んだのかまでAIに伝わらないからです。
この日のゴールは、AIに一度で完璧に覚えさせることではありません。
「操作の手順」「途中の判断」「確認する場所」の3つを、AIと人間の両方が読める形へ変えることです。作業後にAIへ手順書を作らせ、人間が抜けを直す方法でも構いません。
最後に、その手順だけを読んだ別の人でも同じ作業ができるか確認すると、説明不足の箇所を見つけやすくなります。
分からない部分が残ったら、その場で補足し、次に同じ質問が出ないよう手順書へ追記します。

3日目：入力と完成形を固定する

AIが何を読めば仕事を始められるのか。そして、最後に何を作れば完了なのかを明確にします。
たとえば、

入力：先週分の問い合わせ一覧
完成：内容別に分類し、優先順位と返信案を付けた表
のように決めます。
「良い感じにまとめて」ではなく、必要な項目、並び順、文字数、出典の有無などを具体的にします。
完成形が曖昧なままでは、AIの仕事が良かったのかどうかも判断できません。
さらに、完成条件をチェックリストにします。
たとえば記事調査なら、

指定した期間の情報だけを使っている
本人または公式の出典URLが付いている
事実と記事側の解釈が分かれている
同じ事例が重複していない
読者が真似する方法が書かれている
と決められます。
「良い記事」のような感覚的な言葉を、確認できる項目へ分解するんです。
また、AIが判断できない場合の出力も決めておきます。
分からない内容を推測して埋めるのではなく、「確認できない」「追加資料が必要」「人間の判断が必要」と表示させます。
この日のゴールは、入力、出力形式、完成チェックリスト、不明時の対応という4点を一枚にまとめることです。
過去の良い完成物があるなら、それも見本として一つ添えてください。抽象的な説明だけより、仕上がりの基準を伝えやすくなります。
反対に、避けたい完成例もあれば、何が問題なのかを一緒に示すと判断基準がさらに明確になります。

4日目：人間が確認する場所を決める

どこまでAIへ任せ、どこから人間が確認するかを決めます。
特に、

外部へメールやメッセージを送る
商品やサービスを購入する
情報を公開する
ファイルやデータを削除する
健康やお金に関する判断をする
といった操作は、自動実行させず、人間の確認を残します。
便利さだけでなく、間違えたときの影響から考えることが大切です。
作業を、3段階に分けると整理しやすくなります。
自動で任せる部分
資料を集める、並べ替える、下書きを作るなど、失敗しても元へ戻しやすい作業です。
人間へ確認を求める部分
判断が分かれる内容、外部へ見せる文章、金額や個人情報を含む処理です。
AIへ実行させない部分
高額な購入、重要データの削除、法的・医療的な最終判断など、間違えたときの影響が大きい操作です。
そして、確認を求めるときに、AIが「実行してよいですか？」だけを表示するのでは不十分です。
何を実行するのか、対象は誰か、変更前後で何が変わるのか、元へ戻せるのかを一緒に表示させます。
この日のゴールは、仕事の流れの中へ「人間が止める場所」を明記することです。
確認者が自分以外の場合は、誰に、どの方法で、何を添えて確認を求めるのかまで決めておくと、途中で仕事が止まりにくくなります。
返事がない場合は実行しない、という停止条件も忘れずに決めておきます。

5日目：実際に一度動かす

完璧な仕組みを先に作ろうとせず、まず1回分の仕事を通します。
どこでAIが止まったか。
どの情報が足りなかったか。
人間が何度も説明し直した部分はどこか。
実際に動かしてみると、頭の中だけでは分からなかった問題が見つかります。
最初の目標は完全自動化ではありません。仕事の流れを最後まで一度通し、AIに任せられる部分と任せにくい部分を見つけることです。
テストには、本番の機密情報ではなく、公開情報や架空のサンプルを使えると安全です。
実行中は、次の4点をメモします。

AIが止まり、人間の説明が必要になった場所
AIが勝手に推測した場所
出力は正しいが、確認に時間がかかった場所
人間が作業した方が速かった場所
ここで大切なのは、AIを無理に使い続けないことです。
通常の自動化で十分な処理や、人間が数秒で終えられる作業までAIへ任せると、かえって複雑になります。
一度のテストで完全に動かなくても問題ありません。むしろ、どこで失敗したかが見えれば、次の日にルールへ変えられます。
この日の完成物は「完璧なAI」ではなく、1回分の実行記録と、改善点の一覧です。
処理時間や修正回数も簡単に記録しておくと、仕組みを直した後、本当に負担が減ったのかを同じ条件で比べられます。
速さだけでなく、見落としや手戻りが増えていないかも一緒に確認してください。

6日目：間違いをルールへ変える

AIの間違いを修正したら、その場の会話で終わらせません。
次回も読み込む指示や、チェック項目として残します。
たとえば、

数字には必ず元資料を付ける
顧客名は外部向け文章へ書かない
日付は日本時間で統一する
判断できない場合は推測せず、人間へ確認する
公開前にリンク切れを確認する
といった形です。
一度の失敗を、次回から同じ失敗を減らすルールへ変えます。
ルールは、AIが実行できる言葉で書きます。
「注意深く確認する」
「絶対に間違えない」
だけでは、何をすればよいのか分かりません。
「数字を出す前に、元資料の該当箇所を引用する」
「公式情報を見つけられない場合は、推測で補わず『未確認』と書く」
「外部リンクを一覧化し、公開前に開けるか確認する」
のように、動作と条件を明確にします。
また、ルールごとに「何の失敗を防ぐためのものか」を短く残すと、後で整理しやすくなります。
似たルールが増えたら一つへまとめ、現在の仕事に合わなくなったルールは更新します。
この日のゴールは、テストで見つかった問題を、次回のAIが読めるチェックリストへ変換することです。
ルールを追加したら、同じ入力でもう一度試し、問題が実際に防げたかを確認してください。書いただけで機能するとは限りません。
防げなければ、注意文を増やすのではなく、確認手順や停止条件そのものを具体化します。

7日目：繰り返せる部分だけ自動化する

1回通して問題が分かったら、安定して繰り返せる部分だけを自動化します。

毎日決まった時間に始める
毎週月曜日に実行する
特定のフォルダへファイルが追加されたら始める
フォームへ回答が届いたら整理する
といった開始条件を決めます。
ただし、外部へ送信する、購入する、削除する、公開するといった重要な操作には、人間の確認を残してください。
ここまでやるだけでも、AIは「毎回質問する相手」から、「自分の仕事の流れを理解して動く相手」へ変わり始めます。
海外のAI活用の天才たちは、特別な質問文を知っているわけではありません。
彼らが作っているのは、優れたプロンプトではないんです。
AIが働き、結果を確認し、失敗を次のルールへ変え、次回はさらに良い仕事ができる仕組みそのものです。
最初から10体のAIを動かす必要はありません。
まずは、あなたが毎週繰り返している仕事を一つだけ選んでみてください。
そこへ「実行するAI」だけではなく、「確認する仕組み」と「次回へ残すルール」を加える。
それが、海外の天才たちと同じ方向へ進む最初の一歩です。
あなたが一番真似してみたいのは、15件のうちどれですか？
ぜひ引用で教えてください。
※本記事は2026年7月24日時点で確認できた、本人発信、インタビュー、研究論文、公式運用記録を基にしています。本人の継続運用例に加え、企業の実装例、研究プロトタイプ、公開デモ、提案ワークフローを含みます。作業時間、生産性、減量、速度改善など、第三者による検証が確認できない成果については、本人または企業の自己申告として記載しています。「天才」という表現は、紹介したAI活用法に対する本記事上の編集表現です。