「y」を押す前に実装が消えた ― 自作AIコーディングツールの安全設計
AIの回答を「y」と一言承認しただけで、ファイルの実装が丸ごと消える――そんな挙動をするツールを、なぜ自分でわざわざ作ったのか。社内で使えるAIアシスタント基盤と、それを外部から操作するSDKを使い、チャットでのやり取りだけでローカルのプロジェクトに変更を反映できるCLI/GUIツールを自作した話をまとめます。
作ったもの
AIとの対話とローカルのソースコードを橋渡しするクライアントです。CLI(コンソール)とGUI(Streamlit)の2つのインターフェースを持ち、機能は同じ。できることは大きく3つです。①アシスタント/チャットの一覧を見る、②関連するローカルコードを自動で添付して質問を送る、③AIが提案してきたコードを、人間の承認を挟んでtarget_projectフォルダに自動反映する。この「自動マージ」が最大の特徴であり、一番設計に気を使った機能です。
「回答をコピーしてエディタに貼り付ける」という手作業を挟むと、対話のテンポも、ファイルの取り違えのリスクも無視できません。質問の送信からファイルへの反映までを一気通貫でツール化しよう、というのが出発点でした。設計では、CLI/GUIそれぞれの入出力だけを薄いレイヤーとして切り出し、AIとの通信やdiff生成、ファイル反映のロジックは完全に共通化しました。GUIを追加してもCLI側の挙動が一切変わらない状態を保てたのは、この分離のおかげです。
自動マージの安全設計
「AIの回答をそのままローカルファイルに書き込む」機能は、便利さと引き換えに事故のリスクを抱えます。実際に運用しながら、以下の防御を積み重ねました。
| 防御策 | 内容 |
|---|---|
| 人間の承認を必須化 | 変更前後のdiffを表示し、ファイルごとにy/Nで確認する |
| バックアップの自動作成 | 上書き前に元の内容を.bak<タイムスタンプ>として保存する |
| 書き込み範囲の制限 | 対象プロジェクトフォルダの外側には書き込めないよう、パスを二段階で検証する |
| 原子的な書き込み | 一時ファイル経由で置き換え、途中で落ちてもファイルが壊れないようにする |
部分回答をうっかり承認すると、実装ごと消える
このツールは、AIが出力したコードブロックをファイルの新しい中身として丸ごと書き込みます。部分的な差分を賢く合成する機能はあえて持たせていません。つまり、AIが「この関数だけ直しました」というつもりで一部分だけを回答し、それをよく確認せず「y」と答えると、そのファイルの他の関数はすべて消えて上書きされます。
実際に運用中、この「部分回答の誤承認」が起きかけたことがありました。差分画面で削除行が異常に多いことに気づいて事なきを得ましたが、この経験から「diff確認画面は必ず人間が読むことを前提にした最後の砦である」という設計思想を強く意識するようになりました。
固定バイト数のプレビューが、AIに”それっぽい嘘”を言わせていた
初期の実装では、AIに送るプロジェクト情報として、各ファイルの先頭8KBだけを一律にプレビューとして添付していました。あるファイルが8KBを超えていたため、肝心の実装部分がまるごと見えていない状態になっていたのですが、「なぜ自動反映が動かないのか」と尋ねると、AIは実在しない関数を、あたかも実際のコードを読んだかのように根拠付きで説明してきました。ソースが見えていないはずなのに行番号まで添えて言われると、こちらもつい信じてしまいそうになる。典型的なハルシネーションですが、それが「情報不足のシグナル」ではなく「もっともらしい説明」として出てくる怖さを、身をもって知りました。対策として、質問内容に関連するファイルだけは全文を送り、関連しないファイルはファイル名一覧のみを送る方式に変更しました。AIに「見えていないものを見えているかのように語らせない」ための最も効果的な対策は、結局のところ「見えているものを正しく伝える」ことに尽きると感じています。
まとめ ― AIに任せる部分と、人間が確認する部分の境界線
一連の開発を通じて強く感じたのは、「AIに任せる部分」と「人間が最後に確認する部分」の境界線をどこに引くかが、この手のツールの品質のほぼすべてだということです。変更は必ずdiffで人間に見せてから適用する、バックアップと原子的書き込みで失敗しても元に戻せる状態を保つ、AIに渡す情報自体を正しく設計してハルシネーションの温床を減らす――この原則を、事故や不具合を踏むたびに少しずつ言語化してきました。
バイブコーディングはコードを書くスピードを大きく上げてくれる一方で、その速さに見合うだけの安全網を人間側で用意しておかないと、あっという間に取り返しのつかない変更を積み重ねてしまいます。そのバランス感覚こそが、この種のツールを作る上で一番の学びでした。
関連記事
- 「テスト工程が消滅した」— AI駆動開発 vs 従来開発を全工程で比較してみた — AIと二人三脚で開発を進めるバイブコーディングの実績データ
- Qiita CLI × Claude Code で記事管理を自動化 — 記事IDの罠と仕組み化の教訓 — AIツールとローカル環境をつなぐ別の自動化事例
- 「作っては使わない」を繰り返していた私が、運用コスト0円でアプリを公開できるようになった話 — Claude Codeとの出会いが開発スタイルを変えた原点
- 計画通りにいかない毎日から、道なりに進めるアプリへ ― 『ミチナリ』を作った理由 — 同じNewtonX基盤を使った別プロダクトの開発話