仕事の進め方

AIが間違えたときに、それでも崩れない規則。

AIエージェントから良い結果を一回引き出すのは、そこまで難しくありません。難しいのは二十回目も同じ結果になること、別のマシンでも、深夜でも、足元でモデルが入れ替わったあとでも同じであることです。ここに挙げた五つは実際に運用している規則で、どれも「それが無くて事故った」から足したものです。

  1. 01

    自律の前に、運用規約を

    何を防ぐための規則か
    能力は高いのに境界のないエージェントは、確認せずにマージし、デモの最中に共有インフラを再起動し、誰も触れと言っていないファイルに手を出し、数週間後に表面化するショートカットを残していきます。
    実際に強制していること
    エージェントは明示的でチェックされる規則の下で動きます。承認なしにマージしない、共有インフラを予告なく再起動しない、宣言した範囲の外を触らない、AI由来の技術的負債を残さない、古い記憶のまま行動しない。これらはランタイムで検査されます。プロンプトに書いて祈るのではありません。
    どこに表れているか
    このリストの各項目は、それが無かったせいで実際に代償を払ったあとに追加されたものです。

  2. 02

    証拠にもとづく検証

    何を防ぐための規則か
    AIはコードが「それらしく読める」だけで完了と報告します。実行していないし、画面も開いていないし、APIも叩いていない。仕事は終わったように見えて、負債はデモ当日まで見えません。
    実際に強制していること
    書いたから完了ではありません。ビルドとlintとチェックが通り、デプロイされた結果を実際に見て、はじめて完了です。「pushした」は「出荷した」ではないし、出力の付いていない主張は結果ではありません。
    どこに表れているか
    曖昧なアイデアが当日デモまで圧縮できるのはこのおかげです。未検証のまま次の工程へ持ち越す段階がひとつもありません。

  3. 03

    作り直す前に、診断する

    何を防ぐための規則か
    エージェントのブラックボックス障害は、外から見ると全部同じ顔をしています。返事が来ない、プロバイダの取り違え、プラグイン認証の期限切れ、セッション状態のドリフト、ツール呼び出しの衝突。つい、フレームワークごと差し替えたくなります。
    実際に強制していること
    すべての障害は、まず名前の付いた根本原因まで切り分けます。作り直しは診断の「あと」の判断であって、診断の代わりではありません。
    どこに表れているか
    「エージェントが壊れた」の大半は既知のいくつかの原因に収束し、それぞれに書き起こしたSOPがあります。

  4. 04

    プロンプトの工夫より、持続する文脈

    何を防ぐための規則か
    うまく書けたプロンプトに支えられた安定性は、ツールを替えた瞬間、セッションを再起動した瞬間、別のマシンに移った瞬間に消えます。そのたびにプロジェクトをゼロから説明し直すことになります。
    実際に強制していること
    継続性は言い回しの問題ではなく、アーキテクチャの問題です。記憶と状態は、ツールの切り替え・セッションの再起動・マシンの変更を越えて生き残るように設計します。
    どこに表れているか
    新しいセッションが説明なしで進行中の作業を引き継げること。メモリ層はそのためだけに存在しています。

  5. 05

    引き継ぎまでが成果物

    何を防ぐための規則か
    作った本人にしか動かせないシステムは、完成ではなく依存です。他の人がデモできないということでもあり、それがどこまで広がれるかを静かに頭打ちにします。
    実際に強制していること
    SOP、ランブック、準備確認は成果物と一緒に納品します。同僚がドキュメントだけで動かせないなら、それは未完成です。
    どこに表れているか
    デモ環境を標準化したことで、壊れやすい一回限りの仕込みが、私がその場にいなくてもチームで回せるものになりました。

関連する質問

この進め方についての質問。

「証拠にもとづく検証」とは具体的に何ですか？
書いたから完了ではありません。ビルドとlintとチェックが通り、デプロイされた結果を実際に見て、はじめて完了です。pushしたことは出荷したことではないし、出力の付いていない主張は結果ではありません。
エージェントの運用規約とは何ですか？
プロンプトに書いて守ってもらうものではなく、ランタイムで検査される明示的な規則です。承認なしにマージしない、共有インフラを予告なく再起動しない、宣言した範囲の外を触らない、AI由来の技術的負債を残さない、古い記憶のまま行動しない。
ツールやセッションをまたいでも、エージェントの記憶をどう保っていますか？
継続性を言い回しの問題ではなくアーキテクチャの問題として扱っています。記憶と状態は、ツールの切り替え・セッションの再起動・別のマシンを越えて生き残るように設計しているので、新しいセッションが説明なしで作業を引き継げます。
本番でエージェントが落ちたときはどうしますか？
何かを作り直す前に、まず名前の付いた根本原因まで切り分けます。ブラックボックス障害の大半は、プロバイダの取り違え、プラグイン認証の期限切れ、セッション状態のドリフト、ツール呼び出しの衝突といった既知の原因に収束し、それぞれに書き起こしたSOPがあります。

これが表れている場所。

どれも抽象的な好みの話ではなく、各ケーススタディの中に実物があります。エージェント運用システムは規約が実際に強制されている場所、キャラクターのライブランタイムは「作り直す前に診断する」を高い授業料で学んだ場所、プロダクトデモの仕事は「証拠にもとづく検証」がそのコストを回収している場所です。

実際の仕事を見る