AIの中継役をやめる最初の一歩。自動化の限界、Boris Taneの自己改善ソフト論を解説

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Boris Taneさんの記事「Self-improving software is inevitable」（2026年10月10日）を紹介します。AIが作った物の結果を、人がスクリーンショットで運んでAIに貼り直している。その人を生身の中継役（meat proxy）と呼び、そこをやめようという話です。

なぜ私がこれを書くのか。決めた通りにAIが動かず、管理が私の手に戻ってきた夜があるからです。Taneさんの記事を読んで、あの夜の私は、人が手で運ぶ側に回っていた姿と同じだと考えました。

この記事では、元記事の7つの見出しに沿って、あなたの毎日に置き直して読みます。筋は1つです。AIの中継役をやめる最初の一歩は、AIに何を渡すかより先に、何をもって良くなったとするかを、AIが読める言葉で書き残すことです。ただし、書けるのは私が気づいた直しだけです。Taneさんの言う自動改善は、私の環境ではまだ動いていません。

Boris Tane「Self-improving software is inevitable」（boristane.com・2026年10月10日）の節「Right now, people are the feedback loop」

Agents produce more software, that software produces more signal, and almost none of that signal ever makes its way back to the agents. We are the ones bringing this data back into agents manually.

Taneさんの記事は、きつい一言から始まります。今朝出した新しい版が何を間違えているかは、もう一日中、あちこちに出ている。それでも本番が壊れたままなのは、あなた自身のせいだ、と。

本番とは、お客様が実際に使っている状態のことです。お店の予約ページや、お客様に送る案内文に置き換えて読めば、開発者でなくても同じ話になります。

Taneさんが描く流れは、こうです。AIが物を作る。使われると、記録やクリックや問い合わせといった信号が出る。ところが、その信号はほとんどAIに戻りません。

ここで言う信号とは、使う人が残していく足あとのことです。買った、離れた、困って問い合わせた。その全部が、直す材料になります。

戻しているのは人です。信号を読み、見比べ、直す順番を決め、AIに頼む文章にまとめる。この一連が、手作業になっています。

Taneさん自身、この10年の大半、信号を見やすくする道具を作ってきた人です。それでも、データを読んで何を直すか決めるのは、最後は人だったと書いています。

そこでTaneさんは、自分で信号を読み、直し、直ったかまで確かめるソフトは避けられない、と言います。そのためには、人が次に何を直すか、いつ直すかを決める立場を手放す必要がある、とも。

地味です。でも、AIが作る側を引き受けた今、人に残っているのはこの運ぶ仕事なんです。

私にも、この運ぶ側に回った場面があります。

AI氣道『AI社員に出した修正の指示は、別の仕事でも守られるか。Claude Codeで会社ごと立ち上げるテンプレで6回確かめた』より

「何度決めても決めた通りに動かないAIから、管理が私へ戻ってきました。出てきた言葉は「同じこと何度も何度も決めた通りやらないから腹立つ」。胸がザワザワして、頭がかちんと来ました。」

この場面を、私は『AI社員に出した修正の指示は、別の仕事でも守られるか。Claude Codeで会社ごと立ち上げるテンプレで6回確かめた』で書いています。

Taneさんの言葉で読むと、この場面は、AIの足りない部分を人が手で埋めている姿です。運ぶ人がいる限り、直しはその人の手が空いた時にしか進みません。

ここが大事です。AIの頭が足りないから運ぶのではありません。結果を読む道が、AIにつながっていないから運ぶんです。

Boris Tane「Self-improving software is inevitable」（boristane.com・2026年10月10日）の節「Are we all meat proxies?」

A meat proxy is a person whose only job is to carry information between two machines that could perfectly well talk to each other.

Taneさんは、中継役をはっきり定義しています。分析の画面をスクリーンショットで撮り、Claude Codeに貼って、「このグラフが下がっている理由を調べて直して」と頼む。その人が、生身の中継役だと。

定義はこうです。互いに直接話せるはずの2つの機械の間で、情報を運ぶだけの人。画面にはデータがあり、AIには知恵があります。

その間に座って、何を見るか、いつ見るか、どう言い表すかを決めているのがあなたです。

あなたの毎日に置き直します。売上表を画面ごと撮って、ChatGPTに貼る。お客様からの返信メールをコピーして、Claudeに「どう返すのがいいか」と聞く。アクセスの数字を撮って、「なぜ減ったのか」と頼む。

どれも普通の使い方です。悪いことではありません。

ただ、Taneさんは、接続の仕組みを入れて速くしても、間に座るのがあなたなら、中継役のままだと書いています。

たとえば、貼る画面を選ぶのは、いつもあなたの判断です。先月はこのグラフを貼ったけれど、今月は別のグラフを貼った。見る場所が変わると、AIの答えも変わります。

Taneさんは、画面から直接読めるはずなのに、と点線で描いています。AIは賢くなりました。でも、賢い相手に渡す材料を選ぶのが、人の目と手のままなんです。

自分が中継役かどうかを数える1問があります。先週、AIに貼るために画面を撮ったりコピーしたりした回数は、何回でしたか。

回数が多いほど、あなたは運ぶ役に近いんです。数えるのは、反省のためではありません。どこで運んでいるかが見えると、次の章が自分の話になります。

Boris Tane「Self-improving software is inevitable」（boristane.com・2026年10月10日）の節「Automations have an unknown unknowns problem」

But these automations only ever see what someone already decided was worth seeing. They inherit every blind spot of the system that triggers them.

Taneさんは、AIに仕事を自動で回させる仕組みの話をします。決まった時刻や知らせをきっかけに、AIを動かす仕組みです。本人も自分で作ったそうです。

例はこうです。監視ツールの警報が鳴るたびに調べる。エラーが記録されるたびに、直し案を出す。毎朝、数字を見て、基準を下回ったら調べて直す。

確かに便利です。誰かがパソコンを開く前に、報告書ができあがっています。

でも、Taneさんは弱点を言い切ります。この自動化は、人が見る価値があると先に決めた物しか見ない。決めた人の見落としも、そのまま引き継ぐ、と。

警報や基準の決め方は、必ず不完全になる、とも書いています。複雑なアプリの予想外の動きには、先に警報を張れないからです。

これが unknown unknowns です。知っている問題は、見つかります。知らない問題は、見つける仕組みがそもそも無いので、見つかりません。

お客様を一番失う問題は、ほとんど定義からして、あなたがまだ知らない問題だ、とTaneさんは書いています。

私の環境でも、似たことがありました。前に作った物を探さずに一から作る、という指摘を、記録に残る限りで少なくとも9回受けました。そこで10月8日に、確認の質問を出す手前で、探した跡を調べる仕組みを入れています。

この仕組みは、9回の指摘を受けて、ようやく入りました。

Taneさんの言う、先に決めた物しか見ない自動化の限界が、私の小さな現場でも出ました。

ここが大事です。見えていない問題は、起きて指摘されて初めて、直しとして残せるんですよね。だから、起きた直しを残す場所が要るんです。

Boris Tane「Self-improving software is inevitable」（boristane.com・2026年10月10日）の節「Applications need backpropagation」

We’ve automated the forward pass and kept the backprop manual.

ここからは、少し理科の話です。Taneさんは、ソフトをニューラルネットワークに見立てます。難しく聞こえますが、経営者の言葉に置き直せます。

まず、作る部分。やりたいことを伝えると、AIが物を作って出す。Taneさんは、この前向きの流れ（forward pass）は、AIがほぼ解いたと言います。

1回の依頼でかなり複雑な物が作れて、公開や計測の準備までできます。

もう半分が、戻す流れ（backpropagation）です。出てきた結果を、思っていた形と見比べて、差を測り、直す方向をシステムに戻す。

ソフトでいえば、本番で出る信号を集め、コードに何を言っているかを考え、コードを直すことです。

経営者の言葉にすると、作る側は自動化済みです。結果を見て直しに戻す側は、人が手でやっています。

たとえば、店の看板を毎週1つずつ変えているとします。変えるのは速くなりました。でも、変えて来店が増えたかを確かめるのは、月末に記憶をたどる会だけ。これが、作る側だけ自動化された状態です。

Taneさんは、その戻し方の中身も書いています。変更は毎週何十個も出しているのに、直す方向は、週に1回、会社によっては3か月に1回の会議で、手で決めている。

その会議の材料は、担当者の記憶と、お客様の利用の録画から抜き出した20本ほどと、声の大きかった3件の苦情だ、と。

あなたの会社に置き換えると、どうでしょう。先月のお客様の声のうち、思い出せるのは、一番強く言われた3件だけかな。

Taneさんの言い方では、機械学習のモデルをこんなやり方で鍛えたら、誰も時間を使う価値を感じない物になるそうです。

Taneさんは、作るのが速くなったのだから、戻すのも同じ速さで回せるはずだ、という立場です。

ここが大事です。作るスピードが上がるほど、戻す側の手作業が目立ってくるんですよね。

Boris Tane「Self-improving software is inevitable」（boristane.com・2026年10月10日）の節「Intelligence is now too cheap to meter」

We now have intelligence too cheap to meter. It can read every trace, watch every session, read every ticket and every interview transcript, and join them together in minutes.

戻す側が手作業のままなのは、理由が1つだけだった、とTaneさんは言います。エラーの記録を読み、対応する記録を探し、お客様の画面録画と見比べ、なぜ怒ったのかを理解して、何を変えるか決める。

それができるのは、判断力のある人だけだったからです。

今は違う、とTaneさんは続けます。量を気にせずに使える知能が手に入りました。全部の記録を読み、全部の利用を見て、全部の問い合わせとインタビューの文字起こしを読み、数分でつなぎ合わせられます。

人が週に1回の会議で20本の録画を見ていた仕事を、AIは全件でやれる、という話です。

Taneさんは、その知能を、作る側にも戻す側にも入れようと呼びかけます。そうすれば直す速さが上がり、自己改善するソフトに届く、と。

あなたの手元で試せる形にします。

1週間分のお客様からの問い合わせメールやレビューを、お名前を消してから、ChatGPTかClaudeに貼ります。「同じ問題だと思うものを束ねて、多い順に並べて」と頼みます。

人が読むと、声の大きい数件が頭に残ります。AIに読ませると、小さな声でも、同じ内容が何通も重なっていることを見せてくれることがあります。

束ねた結果は、そのまま信じません。元のメールを数通開いて、本当に同じ問題かを自分の目で確かめます。

束ねる前に、AIに渡す期間を決めておくと、結果を比べやすくなります。先週と今週で、同じ頼み方をするんです。

これは、Taneさんが描く全部の信号を読む仕組みを、手でごく小さくしたものです。元記事は、書き換えの権限まで持つAIの話で、ここで試すのは、読んで束ねてもらうところまでです。

ここが大事です。AIに読ませるのは、直させるためではなく、まず見落としていた声を見つけるためです。

Boris Tane「Self-improving software is inevitable」（boristane.com・2026年10月10日）の節「What’s our role then?」

A neural net without a loss function is just a very expensive random number generator. Backprop needs to know what “better” means.

Taneさんの問いは、では人に何が残るのか、です。良いとは何かを測る物差しが無いニューラルネットは、ただの乱数発生器だ、と書いています。

だから人の役目は、機械が目指す良いを決めることになります。エンジニアも、営業も、サポートも、みんなです。

元記事の表では、エンジニアは表示の速さとエラーの少なさ、プロダクトは申込みに進んだか、使い続けたか、デザイナーは作業を終えられたか、営業は成約と解約、サポートは問い合わせの数と解決までの時間が、良いの例です。

一人で仕事をしているあなたは、この全部の役を一人で兼ねているのかもしれません。申込み、リピート、解約、問い合わせ。どれを良くしたいのか、言えますか。

Taneさんは、難しさも書いています。良いは、よく引っ張り合います。支払いを速くすると、不正の見張りが弱まることがあります。

どれを優先して、どれを絶対の線にするか。それを機械が最適化できる精度で書き残すのが一番難しく、昔から一番難しかった、と言います。

この難しさを、私は小さな実験で見ました。

同じ依頼「相談の申込みLPを作って」を、別の会話で6回出しました。

AI秘書の凛ちゃんが経営者役になり、「キャッチコピーは20字以内」「期間や所要時間は私が言うまで書かずTBDに」と伝え、担当が自分で台帳（feedback.mdとquality-bar.md）に書き足しました。

会社は3種類で各2回です。Aは台帳も前のLPも入れ、Kは台帳と合格ラインだけを移し、Bは直しの追記が無いテンプレのままでした。

AI氣道『AI社員に出した修正の指示は、別の仕事でも守られるか。Claude Codeで会社ごと立ち上げるテンプレで6回確かめた』より（6回の結果）

「直しを残した4回は、見出しが20字以内で、根拠のない時間の数字は0か所。直しがない2回は、見出しが24字と25字、時間の数字が各4か所でした。」

この数字を、私は『AI社員に出した修正の指示は、別の仕事でも守られるか。Claude Codeで会社ごと立ち上げるテンプレで6回確かめた』で書いています。

台帳があった4回は、見出しが15〜17字で、根拠のない時間の数字は0か所でした。無かった2回は、24字と25字で、時間の数字が各4か所です。Bにもテンプレ元の合格ラインはありました。

ただし各条件は2回なので、偶然のぶれと区別できません。Kの2回は、台帳にある見出しと同じ文を使っていて、原則を守ったのか、写したのかも分けられません。

Boris Tane「Self-improving software is inevitable」（boristane.com・2026年10月10日）の節「An era of abundance ahead」

every morning, compare yesterday against these goals: checkout p99 under 300ms, error rate under 0.1%, activation above 25%, fewer than 20 support tickets a day.

最後の章でTaneさんが描くのは、時間割でAIを動かす絵です。クラウドで動くAIに、全部の信号源を読む権限と、コードを書き換える権限を渡し、それを決まった時刻で回します。

例が2つあります。1つ目は毎時間。直近1時間の新しいエラー、記録、画面録画、問い合わせを全部読み、同じ問題に見えるものを道具をまたいで束ね、原因になった版を探して、証拠を付けた直し案を出す。

2つ目は毎朝。昨日の数字を目標と見比べます。例は、支払い画面の応答時間が、100回のうち99回は0.3秒未満、エラー率が0.1%未満、利用開始率が25%超、問い合わせが1日20件未満です。

悪い方に動いた物は原因を探して直し案を出し、全部順調なら、次に数字を動かしそうな変更を探して直し案を出します。

Taneさんは、近いと言います。自己改善するソフトは避けられず、初めて作れるところまで来た、と。

Taneさんが書く、記録を毎時間読んで自分で直すAIは、私の環境ではまだ動いていません。動いているのは、直しを台帳に書き残すところまでです。

台帳に残るのは、私が気づいた直しだけです。つまり、気づけない問題には、私の環境も弱いままです。

AIの間違いに腹が立った時の、私の基本の構えです。

AI氣道『ＡＩ時代、腹が立つのは、仕組み改善の合図なのか』より

「腹が立った事実は消さない。消さないまま、仕組みに変える一歩だけ足す。」

この一文を、私は『ＡＩ時代、腹が立つのは、仕組み改善の合図なのか』で書いています。

それでも、同じ間違いを2回、3回と繰り返された時は、感情のまま終わらせず、指示や設計のどこが抜けていたかを見るようにしています。その見た結果を置く場所が、台帳です。

今日の一歩は小さいです。ChatGPTやClaudeへの依頼文の1行目に、何をもって良くなったとするかを書きます。

たとえば「返信メールの案を作って、良い返信とは相手の質問に最初の2行で答えていること」。次に同じ依頼をする時は、その1行を最初に貼ります。

ここが大事です。AIに何を渡すかより先に、何をもって良くなったとするかを書くんです。書き残した1行は、AIが読める物差しになります。

Boris Taneさんの記事は、AIが作る側を引き受けたのに、結果を戻す側は人が手で運んでいる、という話でした。画面を撮ってAIに貼る人を、生身の中継役と呼びます。

時間割で動く自動化にも、弱点があります。先に人が決めた物しか見ないので、まだ見えていない問題は直りません。私の場合、前に作った物を探さないという指摘が9回続いて、ようやく仕組みが入りました。

人の役目は、何をもって良くなったとするかを決めて、書き残すことです。私の小さな実験では、直しを台帳に残した回の方が、次の依頼で違いが出ました。ただし各条件2回なので、断定はできません。

Taneさんが描く、毎時間信号を読んで直すAIは、私の環境ではまだ動いていません。書けるのも、私が気づいた直しだけです。

だから今日の一歩は、1行です。次にAIへ頼む時、依頼文の1行目に、何をもって良くなったとするかを書いてください。運ぶ人から、物差しを置く人へ。そこから始めます。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！