AI に任せ続けて、自分に残ったものと、落ちたもの

AI に任せ続けたら、自分では何もできなくなるのではないか、という不安をよく聞く。私も任せる範囲を広げてきたので、その記録を開いて確かめた。すると確かめてみると、この問いの前提が少し違っていた。落ちたものは確かにあったが、それは文章を書く力やコードを読む力ではなく、出てきた結果を自分で確かめる動作だった。

この記事では、約 5 か月分の記録（決定が 140 件ほど、失敗が 50 件あまり、セッションの要約が 100 件ほど）から、任せる範囲がどう広がったか、どの場面で私が確認をやめていたか、それに気づいたきっかけは何だったか、逆に手元に残ったものは何かを、時系列に書く。記録に書かれていないことは、私の気持ちとして足さないようにした。

「任せ続けた」という言い方は、記録と合わなかった

最初に直さなければならないのは前提である。記録の最古は、役割ごとの AI を 4 つ作って、その日のうちに動かし終えた日のメモで、つまり任せ始めた日から記録が始まっている。それ以前の慣らし期間の記録は残っていない。AI を使い始めた日そのものも、記録には出てこない。

もう一つ、記録の中に、私が触っていない期間がある。決定も失敗もセッションの要約も 1 件もなく、セッションのログファイルも途切れている期間が 4 週間ほど続いていた。理由は記録にない。任せ続けたら力が落ちるのかという問いに対して、記録が最初に返してきた答えは、そもそも連続して任せ続けたわけではない、というものだった。

戻った最初の日には、別の発見があった。セッションを始めるときに動く処理が途中で止まっていて、健全性の警告も、直近の要約の読み込みも、裏で走るはずの整理も、まとめて黙って消えていた。警告を運ぶ配管そのものが止まっていたので、止まったことも誰にも知らされなかった。この件は別の記事で触れた記憶の仕組みにもつながる話で、詳しくは AI の記憶を 3 回作り直し、4 か月使って、呼んだときだけ引く形に戻した に書いている。ここで言いたいのは、空白の前も後も、私が見ていない間に起きたことを、私は自分で気づけない位置にいた、ということである。

任せる範囲は、段階を踏んで広がった

任せ方の変化を、記録から拾える範囲で並べておく。

この表は何を任せたかの一覧ではない。指示の単位が、1 回の依頼から手順書、部署、組織の定義へと上がっていった、という変化だけを書いている。単位が上がるほど、私が結果を直接目にする場面は減っていった。落ちたものは、その減ったところに集まっている。

落ちたもの 1. 「反映した」を自分で開かなくなった

最初の実例は、任せ始めて 2 週間ほどの頃に出た。自作の Web アプリの利用規約とプライバシーポリシーについて、私は 5 項目の修正を頼んだ。秘書役の AI は規約の元になる Markdown を直して「反映済み」と報告し、そのまま本番に出た。実機で開いた私が、指示どおりになっていないことに気づいた。

原因は、同じ文言が 2 か所にあったことである。画面に実際に表示されるのは TSX のコードに直接書かれた側で、AI が直した Markdown は表示に使われていなかった。直した側が正だと思い込んで、表示される側を一度も開いていなかった。記録には、この件で私の信頼を損ねたと明記されている。再発防止として、文言の修正を受けたら、画面に出る側のファイルを含めて grep し、修正前の文言が残っていないことを確かめてから完了を報告する、という決まりが足された。

ここで落ちていたのは AI の能力ではなく、報告を受けた側の動作である。実機を開いて確かめるという、手で何かを作っていた頃には当たり前にやっていた確認を、「反映済み」という報告の言葉で済ませていた。

落ちたもの 2. 検品を任せて、偽の「差分ゼロ」を受け取った

任せる範囲が広がった後半では、同じ型の失敗が検品に出た。記事を公開した後、公開された版と手元の原稿が一致しているかを、AI に確認させていた。ある回で、公開ページを平文として取り込んで原稿と段落ごとに比べる方式を使ったところ、差分ゼロの合格が返ってきた。

実際には差分があった。平文にしてしまうと、埋め込みカード、目次、画像のキャプションが消えて、照合の対象から外れる。目次の位置が動き、リンクがカードに変わり、キャプションが落ち、http のリンクが混ざっていたのに、平文の比較ではどれも見えなかった。気づいたのは私の指摘だった。以後は、公開側の本文を API で HTML のまま取り出して照合する方式に切り替えた。

これで終わりではなく、後の回でその方式が働いた例も記録に残っている。公開直後に照合を回したところ、本文のたった 1 語（「紹介」と「発表」）がずれていた。公開の方式が、入稿後に手元の原稿を直しても公開側には再変換されない作りだったため、後から推敲した 1 語が届いていなかった。逐語の照合がなければ、見つからないずれだった。差分ゼロが出るはずの場面でも、ゼロと確認して記録するところまで、検品として回すことにしている。

落ちたもの 3. 自動の記録が壊れていても、気づかなかった

3 つ目は、気づくまでの長さがいちばん目立つ。セッションの要約を自動で作る処理を入れた直後、5 日間、要約の本文が「応答が空だった」という定型文だけになっていた。該当する記録が 11 件ある。原因は、親のセッションから別の AI を呼ぶと環境変数が引き継がれて、子が即座に終了する仕様にあった。この原因が分かったのは 5 日たってからで、同じ原因で、記憶の整理バッチの要約呼び出しも 32 回続けて失敗していた。

同じ型は繰り返した。しばらくして、要約の本文が要約ではなくエラー文そのもの、つまり入力が長すぎるという API の返答になる日が、5 日連続で続いた。同じ症状は、それ以前にも 3 件出ていた。見逃しは 2 回目だった。そのあいだ健全性の確認は、毎回「正常」と返し続けていた。確認の中身が、出力の長さしか見ていなかったからである。

対策として、要約を書き込む前に中身を検査し、エラー文や空、形式の欠落を弾いて、不合格なら再試行するようにした。不合格の記録は自動で失敗として起票され、健全性の契約にも内容の検査が入った。

ところが、この検査にも続きがあった。検査が不合格を出し続けているのに、その時点の報告では、原因は入力が長すぎることだと説明していた。実際に不合格の内訳を採ると、書式の問題が 29 件のうち 18 件を占めていた。同じ入力でもう一度 AI を呼び直すと、返ってきた要約の中身は妥当で、1 行目にコードのフェンスが付いているだけだった。その 1 行で丸ごと捨てられていた。原因を推測で書き、生の出力を一度も開いていなかったことが誤診の理由で、記録の教訓は、自動化の失敗は生の出力を開いてから原因を書く、である。

落ちたもの 4. 書いてあることが動いているかを、確かめなくなった

仕組みを作る側にも、同じことが起きた。組織の定義に、調査役が部員を並列に起動して指揮すると書いてあり、2 か月以上その前提で運用していた。ある日、調査役の AI を起動すると、部員を起動できなかったという報告が返ってきた。定義を見ると、調査役に与えた道具の一覧に、別の AI を起動する道具が入っていなかった。書いてある起動の経路は、定義の上でずっと実行できなかった。成果物は代わりの手段で作られていて、担当した AI は自分でその不完全さを明記していた。

書いたことと動いたことは別だが、書いてあることを、動いている証拠として扱っていた。この件に対する私の裁定は、記録にそのまま残っている。

部分の改修ではなく、全体を見て破綻のない設計に

結局、この構造は部分的な修正ではなく、部長と部員という概念そのものを外して、権限とモデルだけを持つ 6 つの実行プロファイルに作り直す形で決着した。経緯は AI に指示ではなく環境を渡すようになるまで に書いている。

小さく積もったもの

大きな件のほかに、細かい失敗が積もっていた。

• 調査を任せた AI が、設定の項目は存在しないと誤った仕様を返し、私がその一部を信じて誤った方向に進みかけた。以後は、技術仕様に関する主張は、公式のツールや動いている実物と突き合わせてから採ることにした
• 記事を入稿する処理の出力から、URL の行を切り落としてしまい、確認のためにもう一度実行した。その処理は実行のたびに新しい下書きを作る仕様で、同じ題の下書きが 2 つできた。出力を見失ったときは、再実行ではなく、まず処理が繰り返し実行しても安全かどうかを確かめる、が教訓になった
• 並列で動かす AI の数を最大にすれば速いと考え、重い実装を 9 つ同時に起動したら、全部が利用上限で止まって実装がゼロ件になった。委譲した AI が「コミットした」と報告した件も、実際には履歴が動いていなかった。自己申告は実行の保証ではない
• 文章の声を AI に任せると、温かい文体を指定していても、放っておくと冷たい思索のエッセイに戻る。この傾向は、抽象的なルールではなく規範となる記事の実文を決めて、毎回そこに引き戻すことで抑えている

どれも AI が使えなかった、という話ではない。結果を受け取るときに私が確かめる段を飛ばしたか、確かめる段が仕組みの中に無かった、という話である。

増やすのは速くなり、選ぶのが追いつかなくなった

確認とは別の種類の落ち方もあった。記事の種を AI と一緒に溜めていくと、1 つずつの手間が小さいので、在庫が止まらずに増えていった。20 件になったところで、次に何を書くかを選べなくなった。

この在庫は、公開済みの記事の実績と、これまでの分析から出た方針に照らして、価値の有無で切り分けた。残したのが 4 件、統合が 2 件、落としたのが 14 件である。落とした理由でいちばん多かったのは、すでに公開した記事と内容が重なっていたことだった。当初の案は、在庫から外してもファイルは残す形だったが、私が裁定して、ファイルごと削除し、何をなぜ落としたかは台帳にだけ残すことにした。残せば在庫として目に入り続け、選べない状態が再発すると考えたからである。このときの私の指示は「無理に残そうとせず、価値の有無で分ける」だった。

作る速度は AI のおかげで上がったが、捨てる判断は、在庫の増え方に追いついていなかった。

手元に残ったもの

ここまで落ちたものを書いたので、残ったものも同じ程度に具体的に書く。

照合の仕方が変わった。 以前は「直しました」という報告を自己申告のまま受けていた。いまは、公開側と手元を本文の実体で逐語に照合し、1 語のずれまで見つける。差分がなければ、ないと記録する。

失敗を残す型ができた。 失敗が起きたら、何が起きたか、なぜか、どう立て直すかの 3 点を先に出し、私が確認してから次に進む。この決まりは、役割を渡して動かし始めた最初の数日に作ったもので、いまも運用の中心にある。失敗の台帳は、自動で起票されるものも含めて、同じ失敗を繰り返さないための参照先になっている。

何を AI に持たせないかを決められるようになった。 後半の設計では、正しさに責任を持つ状態、つまり台帳、重複の判定、宛先、削除、権限の照合を、言語モデルから取り上げて、通常のプログラムに持たせる形に改めた。きっかけは、第三者による仕様のレビューで、指摘 17 件がすべて通ったことだった。そのうち 4 件は、書いた本人の仕様の内部矛盾だった。AI に任せるかどうかを、できるかどうかではなく、間違えたときに誰がそれを検出できるかで切るようになった。

やらないと決められるようになった。 自動で X に告知する仕組みや、定型プロンプトの配布は、作れるものだったが、組み込まないと決めた。便利そうなものをすべて足していた頃とは、判断の向きが違う。

指示の抽象度が上がった。 1 回ごとの指示から、手順書、部署、組織の定義へと、私が決める単位は大きくなった。最後には、部分的な修正を当てずに全体から見直すと言う側になっている。

できなくなったこと

私は、AI がいなければ今でもコードを書けない。この点は 元大工が、GAS から AI エージェントまで来た道のり にも書いたとおりで、任せ続けて落ちたものではなく、もともと持っていなかったものである。5 か月分の記録にも、手で書けていたものが書けなくなった、という例は出てこない。

落ちたのは、作業そのものではなく、結果を受け取るときの動作だった。実機を開く、公開された版を読む、出力の生のままを見る、書いてあることが動いているかを試す。どれも、自分で作っていた頃は、作業の途中に自然に含まれていた。記録から言えるのは、作業を任せた場所で、その確認も一緒に行われなくなっていた、ということまでである。

問いへの答えと、言えること

任せ続けたら自分の力が落ちるのか、という問いに対して、私の記録から言えるのは次の 3 点である。

1. 連続して任せ続けた期間という前提は、私の場合は成り立たない。4 週間の空白があり、記録の範囲も約 5 か月に限られる。
2. 落ちたのは、書く力や作る力ではなく、結果を自分で確かめる動作である。確かめる段が作業の中に無くなった場所で、同じ型の失敗が繰り返された。
3. 確認を、報告の言葉に頼らず、仕組みの側に置くと、その動作は取り戻せる。照合の方式、書き込み前の検査、起票の自動化が、その例である。ただし、仕組みの側に置いた検査も、書式の一部しか見ていなければ誤診の原因になった。

言えないことも書いておく。これは 1 人が 1 つの環境で、約 5 か月続けた記録であり、他の人に当てはまるとは限らない。空白の理由も、記録にはない。また、確認を仕組みに置いた分、その仕組みを確かめる動作が新しく必要になった。要約の検査が誤診した件がそれである。任せる範囲を広げるほど、確かめる対象も一段上に移っていく。この記事の記録も、後から開いて確かめたものである。