「AIが勝手にやった」と言い訳しないために。自律エージェント時代にエンジニアが握るべき「最後の聖域」

---

はじめに：AIの出力に「違和感」を覚えたあの日

自律型AIエージェントの進化スピードには、目を見張るものがあります。プロンプトを投げるだけで、関連ファイルを横断検索し、計画を立て、コードの修正からリサーチのまとめまで一気にこなしてくれる。「人間が手を動かす時代は終わった、これからは全自動だ」という熱狂的な言葉も、毎日のようにタイムラインを流れていきます。

私自身、日々の個人開発や情報発信、ワークフローの自動化において、AIエージェントを毎日の相棒として動かしています。その生産性の高さは疑いようがありません。

しかし、実務で深く使い倒せば倒すほど、ある時期から胸の奥に強烈な違和感が居座るようになりました。

「ちょっとした修正を頼んだだけなのに、頼んでもいないファイルまで勝手に書き換えて迷走している」
「出てきた文章やロジックが、一見きれいだが、自分の考え方や美学とどこか決定的にズレている」
「そのズレを直そうとプロンプトで注意書きを重ねるうちに、何十往復も指示を出し直し、結局人間が疲弊している」

画面の前でため息をつきながら手動で差分を直しているとき、ふと我に返りました。

「自分は自動化で自由になったはずなのに、いつの間にかAIの粗探しをする検品係になっていないか？」

そして何より恐ろしいのは、もしこのまま出力されたものを世に出して問題が起きたとき、心のどこかで「いや、AIが勝手にやったから」と言い訳してしまいそうな、成果物に対するオーナーシップ（当事者意識）の喪失でした。

これまで私は、勝手な深掘り探索を減らす事前申告ルールやガードレールの設置といった「守りの技術論」を試行錯誤してきました。しかし、その先で突きつけられたのは、もっと根源的な「エンジニア自身の主権（意思決定の所在）をどこに置くか」という問いでした。

AIはどこまで自律で動かすべきで、人間はどこに踏みとどまるべきなのか。
試行錯誤の末にたどり着いた、現場の境界線についてお話しします。

---

1. なぜ「プロンプトによる説得」は破綻しやすいのか

AIエージェントがこちらの意図や美学と違う動きをしたとき、私たちが真っ先にやってしまいがちなのが「プロンプトでなんとか縛ろうとすること」です。

• 「関係のないファイルは絶対に触らないでください」
• 「出力フォーマットは1文字も崩さず、JSONの型を守ってください」
• 「主観的な推測は入れず、事実だけを淡々とまとめてください」

何十行もの禁止事項やルールをプロンプトに書き連ね、モデルを「説得」しようと試みます。

しかし、現場で痛感したのは、プロンプトだけで厳密な規律を保証しようとすること自体に限界がある、という事実でした。

LLMは指示に沿った出力を生成するための極めて強力な仕組みですが、「その指示に従おうとすること」と「システム上の制約が物理的に守られること」はまったくの別問題です。

モデルがどれほど賢くプロンプトを解釈しても、外部ツールの権限やファイルシステムの制約、排他制御までをモデル自身が完全に保証することはできません。だからこそ、形式や権限、書き込み先といった機械的に検査できる条件は、プロンプトによるお願いではなく、実行するプログラムやアクセス制御の仕組みで強制する必要があります。

AIの進化がどれほど加速しても、「指示を受ける側」にすべての規律と安全を丸投げする設計は、工学的に脆さを抱え続けます。

---

2. 「判断はAI、決定はコード」——二層防御アーキテクチャ

この課題を解決するために私が構築したのが、以前「二層防御アーキテクチャ実践論」でも触れた、「生成層（AI）」と「規律層（決定論的コード ＋ 人間）」の分離をさらに発展させた境界線設計です。

flowchart TD
    A["人間の思考・一次情報<br/>（Obsidianに蓄積された断片）"] --> B["【第1層：生成層（AIエージェント）】<br/>・下調べ、ドラフト作成<br/>・アイデアの壁打ち、多角分析<br/>（※本番や既存資産への直接反映は禁止）"]
    B --> C{"【第2層：規律層（コードによる物理ゲート）】<br/>・Pythonスクリプトによる構文/型検査<br/>・排他的作成やアクセス権限による上書き遮断<br/>・差分Markdownの自動検証"}
    C -- "規律違反" --> D["即時エラー停止 / 物理ブロック<br/>（プロセスの強制終了）"]
    C -- "検査合格" --> E["【最後の聖域：人間の承認ゲート】<br/>・オーナーによる目視確認<br/>・「確定・本番反映」ボタンをクリック"]
    E --> F["安全な本番反映<br/>（WordPress / 本番DB / 公開）"]
    style B fill:#121212,stroke:#7DCA7E,stroke-width:2px,color:#fff
    style C fill:#7DCA7E,stroke:#000,stroke-width:2px,color:#000
    style E fill:#121212,stroke:#7DCA7E,stroke-width:2px,color:#fff
    style F fill:#121212,stroke:#7DCA7E,stroke-width:2px,color:#fff

① AIには「下準備と発想」を徹底させる（第1層）

AIエージェントには、リサーチの整理、コードの下書き、構成案の提案など、圧倒的な処理スピードが活きる領域を任せます。ただし、「本番環境や完成済みファイルへの直接書き込み権限」は物理的に与えない設計にします。作業は必ず作業用の一時ファイルやドラフト領域に限定させます。

② 形式と上書きの検査は「決定論的コード」で行う（第2層）

Frontmatterのフォーマット、タグの整合性、文字数のハードリミット、既存ファイルの重複チェックなどをプロンプトでお願いするのは完全にやめました。

例えば、本番予約枠への書き込みです。AIに「既存ファイルは上書きしないで」と指示するだけでは、誤操作を確実に防げません。

そこで、書き込みを担当するプログラム側に、既存ファイルへの上書きを拒否する仕組みを実装します。ローカルファイルであれば、事前に存在を確認するだけでなく、実際に書き込む瞬間にも排他的な新規作成（Pythonの open(path, "x") モードなど）を用いてアトミックに競合を遮断します。

# 決定論的コードによる排他的新規作成（既存ファイルがあれば即座に例外で失敗する）
try:
    with open(production_target_path, "x", encoding="utf-8") as f:
        f.write(approved_content)
except FileExistsError:
    # 既存の完成原稿が存在する場合は、問答無用で物理停止
    raise SystemExit(f"本番予約枠 [{production_target_path}] が既に存在するため、処理を中断しました。")

重要なのは、事前の存在確認だけに甘えず、実際に書き込む瞬間にも競合や権限を制御することです。さらに、AIエージェント自身に本番環境への直接書き込み権限を与えず、「人間が承認した処理だけが本番変更を実行できる構造」を維持します。

③ なぜ個人開発の単一正本（SSOT）に「Markdown（Obsidian）」を選ぶのか

なぜ専用の管理DBではなく、Markdown（Obsidian）を単一正本（SSOT）に据えるのか。

それは、私の個人開発において「人間が普段の作業環境で直接読み書きできること」と「AIが同じファイルを扱えること」のバランスを最優先しているからです。

Markdownなら、Obsidianで内容を確認・修正でき、Gitで変更差分も追えます。専用の管理画面やデータ変換の仕組みを新たに作らずに済むため、個人運用では管理コストを大幅に抑えやすくなります。

もちろん、Markdownがあらゆる用途でデータベースより優れているわけではありません。複雑な構造化データの検索や、複数ユーザーによる同時更新が必要になれば、データベースを採用する合理性があります。重要なのは形式そのものの優劣ではなく、「人間が内容を検証でき、変更履歴を確実に追跡できる構造を選ぶこと」なのです。

---

3. 成果物に「責任を持つ」という感覚を取り戻す

この二層防御を導入して、日々の開発や制作において劇的に変わった点があります。それは、単に「エラーが減った」「手戻りが少なくなった」という作業効率の話だけではありません。

もっとも大きな変化は、「自分が作った成果物に、再び誇りと責任を持てるようになったこと」でした。

完全自動化を目指してAIに丸投げしていた頃は、出来上がったものに対してどこか他人事でした。「AIがそう言ったから」「AIがこのコードを書いたから」という甘えが心の片隅にあり、不具合が出ればAIの性能のせいにし、自分の手柄にも感じられませんでした。

しかし、
– 何を作るかという一次情報の種を自分が蒔き
– AIに下ごしらえを全力で走らせ
– 機械的なルールは冷徹なコードで守らせ
– 最後に「これで世に出す」と決めてトリガーを引くのは自分自身である

という境界線を引いた瞬間、AIは「自分を脅かす自動化のブラックボックス」から、「自分の表現力を何倍にも拡張してくれる、最高に頼もしい相棒」へと変わりました。

手元に残る成果物は、AIの出力そのものではなく、「自分の意思と美学が通った作品」になるのです。

---

4. これからのエンジニアが握るべき「最後の聖域」

AIモデルの性能はこれからも凄まじい勢いで進化し続けるでしょう。推論能力は高まり、エラー率は下がり、一見すると人間が介在する余地はどんどん狭まっているように見えます。

しかし、モデルがどれほど賢くなっても、安易にAIへ委ねてはいけない領域があります。

1. 「何に価値を感じ、何を世に問うか」という思想・美学の決定
2. 「この成果物を世に出す」と決め、その結果に対する責任を引き受けること

この2つを放棄してフルオートに逃げてしまうと、私たちは単なる「AIの出力の垂れ流し係」になってしまいます。

エンジニアが握るべき最後の聖域とは、プロンプトのテクニックでも、最新ツールの乗り換え競争でもありません。
「AIの自律的な暴走をコードで手なずけ、人間が責任を持って最後の決定権を行使する境界線」を設計し続けることこそが、これからのAI時代に求められる真のエンジニアリングなのだと確信しています。

---

---