0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェントはスキルでひたすら実行して、おかしな点あったら修正と再発防止をセットで命令するようにしよう

0
Last updated at Posted at 2026-09-14
Page 1 of 2

日曜の朝、記事の執筆・公開を自動化しているスクリプトが、また止まった。403 Forbidden。トークンのスコープは合っている。読み取り系のAPIは同じトークンで普通に通る。なのに投稿だけが弾かれる。

このエラーメッセージ、前にも見た。しかも、原因も直し方も、そのとき確かに分かったはずだった。

「CI/CD」というタグが投稿を止めていた

自分のリポジトリには、技術記事の執筆から公開までをAIエージェントに任せている自動化ツールがある。トピック選定から執筆、レビュー、投稿までを一通り任せ、自分は最後にyを押すだけの運用だ。最初にこの403に出会ったのは、CI/CDパイプラインの仕組みを解説する記事を書いた日だった。タグにも当然CI/CDと入れた。投稿スクリプトを叩くと、403 Forbiddenが返ってきた。

原因は数分で分かった。タグ名にスラッシュが含まれていると、トークンのスコープが正しくても投稿先のAPIが弾く。CI/CDCICDに直したら、あっさり通った。

「原因分かった、直った」。その場ではそれで満足していた。タグを書き換えて再投稿し、リポジトリの状態を元に戻し、作業を終えた。

数週間後、TCPとネットワーク周りの記事を書いていて、また403が出た。タグに入れていたTCP/IPが、まったく同じ理由で弾かれていた。エラーメッセージも、原因も、直し方も、一言一句違わず同じだった。何かが引っかかった。

二回目に気づいたのは、直し方ではなく忘れ方だった

二回目の403で引っかかったのは、エラーそのものより、「この原因、前にも突き止めたはずなのに」という苛立ちに近い感覚のほうだった。同じ数分を、また払わされている。

AIエージェントに実装や作業を任せる運用は、基本的に「スキルの通りにひたすら実行させて、結果だけ確認する」形になっている。うまくいっている限り、これはとても速い。ただし、うまくいかなかったときに何が残るかは、まったく別の話だ。

一回目の403で起きていたことを分解すると、こうなる。エージェントはエラーの原因を突き止め、その場のタグを書き換えて、投稿を成功させた。作業としては完璧だ。ただし、その修正が及んだ範囲は「その記事のそのタグ」だけだった。原因の知識は、そのセッションの会話の中にしか存在しなかった。セッションが終われば、それも消える。次にスキルを起動したエージェントは、前回と同じ状態から出発する。

新人研修(OJT、現場での実務を通じて行う教育)に例えると分かりやすい。同じ失敗を指摘されるたびに、その場で直してもらって終わる研修と、指摘のたびにチェックリストが1行増えていく研修では、半年後の再発率がまったく違う。前者は指導した本人の記憶にしか蓄積しない。後者は、指導した相手が変わっても、次の人が同じチェックリストを読める。

AIエージェントとの関係は、後者に寄せておかないと成立しない。エージェントは指導される側でもあり、指導を記憶に留められない側でもある。次のセッションのエージェントにとって、前回の学びが存在するかどうかは、その学びがファイルに書き込まれているかどうかだけで決まる。

「直して」だけでなく「直して、二度と起きないようにして」をセットで命令する

この一件のあと、運用のルールを一つ変えた。スキルの実行中に何かおかしな挙動やエラーに気づいたら、その場の修正だけでは終わらせない。原因と対策を、スキルの指示ファイルそのものに書き足すところまでを、一つの作業として指示する。

実際、今使っている自動投稿ツールの指示書には、この403の一件が「タグ名にスラッシュやスペースを含めないこと」というトラブルシューティング項目として残っている。同じことは、記事のレビュー工程でも起きていた。太字の範囲に全角括弧と英語表記(Authenticationのような表記)を混ぜると、装飾が崩れて**がそのまま記号として表示される、という表示上の癖がある。これも一度レビューで指摘されたきり忘れていたら、何度でも同じ指摘を受けていたはずだ。今はこれも指示書の注意事項として固定されている。

技術的な正確さについても同じことをしている。ある記事で、実際には最新版のライブラリが防いでくれている攻撃を「成立する」と書きかけたことがあった。このときの教訓は、感想として流すのではなく、「脆弱性解説の記事は、攻撃コードを手元の対象バージョンで動作確認してから公開する」という具体的な手順として、執筆の記録ファイルに残した。感想は読み返されないが、手順は次の実行時に読み込まれる。

再発防止をセットにする、というのは特別なことをしているわけではない。ただ、直した内容を「会話」の中に置くか、「ファイル」の中に置くかの違いでしかない。会話は次のセッションに引き継がれないが、ファイルは引き継がれる。この違いを軽く見ていたせいで、自分は同じ403に二度も足を止められた。二度目に感じた苛立ちは、正直に言えば自分自身への苛立ちでもあった。

まとめ

  • AIエージェントにスキルの実行を任せる運用では、その場の修正はセッションが終わると消え、次の実行に引き継がれない
  • おかしな挙動に気づいたら、修正の指示と一緒に「同じ問題が二度と起きないよう指示書やチェック項目に反映する」指示をセットで出す
  • 会話に残すのではなく、スキルの指示ファイルや記録ファイルに残すことが、そのままエージェントにとっての再発防止になる
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?