AIを使い始めた会社員がぶつかりやすい壁がある。「指示するたびに自分が確認して、また指示して……」という繰り返しで、結局手間が減らないという感覚だ。Tesla元AI責任者でOpenAI共同創業者のAndrej Karpathyは、この構造をひと言で表した。「自分をボトルネックにするな」。この記事では、その言葉の背景にある「ループエンジニアリング」という考え方と、仕事への活かし方を整理する。
「ちょっと聞くだけ」が積み重なる問題
AIを使い始めた当初、ほとんどの人は「ChatGPTに聞いて、答えを見て、また聞く」という使い方をする。これ自体は悪くない。ただ、このやり方には構造上の限界がある。AIが次に何をするかを毎回自分が決め、出力を毎回自分が確認してからでないと次へ進めない。人間が「進行係」になっている状態だ。
たとえば、週次の営業レポートをAIで作ろうとしている30代のチームリーダーを考えてみる。数字をコピーして貼り、「この数字でレポートを書いて」と送り、出てきた文章を読んで「ここを修正して」と返す。1回では終わらず、3〜4往復することも珍しくない。AIを使っているはずなのに、作業の主体は依然として自分だ。Karpathyの言葉を借りれば、「自分がボトルネックになっている」。
ループエンジニアリングとは何か
「ループエンジニアリング」とは、AIエージェントが自律的に動き続けるための「仕組みそのもの」を設計する考え方だ。難しそうな名前だが、やっていることはシンプルで「人間が毎回やっている2つの判断をシステムに組み込む」ということに尽きる。
通常の手動セッションでは、人間は2つのことを繰り返している。「次に何をさせるか決める」と「出力を確認してOKを出す」だ。この2つが手動のままである限り、AIがどれだけ高性能でも、処理速度の上限は人間の確認ペースになる。ループエンジニアリングは、この「決定」と「確認」の両方を、あらかじめシステム側に設計して埋め込む。結果として、AIは人間が席を外していても次のステップへ進めるようになる。
Karpathyが「少ないトークンを入れるだけで、大量のことが自分の代わりに起きる」と表現しているのはこの状態だ。入力する言葉は短くていい。その代わり、その短い入力が「どんな判断基準でどの順番で何を処理するか」を定義した仕組みを引き金にする、という設計になっている。
手動セッションとループの違い
両者の違いを整理すると、以下のようなイメージになる。
| 手動セッション | ループエンジニアリング | |
|---|---|---|
| 次のステップを決めるのは | 人間（毎回） | 事前に設計した条件 |
| 出力を確認するのは | 人間（毎回） | 自動チェックの仕組み |
| 人間の関与タイミング | 全ステップ | 設計時と例外発生時 |
| スループット上限 | 人間の確認速度 | システムの処理速度 |
| 向いている作業 | 一回限りの質問 | 繰り返し・連続する作業 |
手動セッションが「毎回自分が運転する」なら、ループは「目的地と交通規則を設定したら自動で走る」に近い。もちろん、完全に放置できるわけではない。例外が起きたとき、方向を修正したいとき、人間が関与する場面は残る。ただ、そのタイミングは「毎回」ではなく「必要なとき」になる。
会社員が実感しやすい場面
ループエンジニアリングの考え方は、エンジニアだけのものではない。繰り返し発生する定型作業を抱えている人ほど、この設計思想が効く。
経理部門で月次の入力照合を担当している人なら、こんな場面が想像できる。現状は「Excelから数字をコピー→AIに確認させる→修正点を報告させる→自分が確認→次の行へ」という流れを数十行分繰り返している。ループ的な設計を取り入れると、「どの条件を満たしたらOKで、どの条件が出たらアラートを上げるか」をあらかじめ定義しておき、AIが条件に沿って全行を処理した結果だけを最後に確認する、という形に変わる。
類似のパターンは、マーケティングのレポート生成、採用候補者のスクリーニング補助、問い合わせメールの分類など、「判断基準が比較的明確で量が多い」作業全般に当てはまる。ChatGPTの使い方ガイドでも触れているように、AIを単なる「返答機械」として使うか、「処理エンジン」として使うかで、実際の生産性はかなり変わる。
設計思想として持っておくべき視点
ループエンジニアリングをすぐにシステムとして実装できる環境にある人は多くないかもしれない。ただ、考え方だけなら今日から意識できる。
「自分が毎回やっていることのうち、条件さえ決まれば自動化できそうなものはどれか」という問いを立てること自体が、ループ設計の入口だ。全部をAIに任せる必要はなく、繰り返し発生する確認作業の一部でも条件化できれば、その分だけ自分の関与は減る。
プロンプトの書き方ひとつとっても、「一回の質問に答えてもらう」プロンプトと、「複数ステップを自律的に処理させる」プロンプトでは構造が変わってくる。後者では「もし○○なら次は△△をせよ」という条件分岐を言語で書き込むことになる。プロンプトエンジニアリングガイドで紹介している条件分岐の書き方は、まさにこの発想に近い。
Karpathyの言葉が示しているのは、技術論ではなく設計思想だ。「自分がいなくても動く仕組みを先に作る」という姿勢を持てるかどうかが、AIをツールとして使う人と、AIに仕事をさせる仕組みを持つ人の違いになっていく。
まとめ
「自分をボトルネックにするな」は、裏返せば「仕組みをボトルネックにせよ」という話だ。すべての判断を自分が担い続ける限り、AIの能力が上がっても出力量は自分のペース以上には増えない。ループエンジニアリングはその構造を変える考え方であり、導入のハードルは高い一方で、思想として持っておくだけでも日々の設計判断は変わってくる。あなたの業務の中で「毎回自分が確認している作業」はどこにあるか、一度リストアップしてみると、最初の一歩が見えてくるかもしれない。
