最初にやりたかったこととクラウド同期への疑問
AIエージェント（Antigravity）を使って作業環境を作っていくにあたり、
まずは土台となる初期設定をどう組むかというところから相談を始めました。
せっかくGoogleのAIプランに入っていてGoogleドライブの容量もテラバイト単位で余っているので、
最初は「データベースそのものをGoogleドライブに置いて、パソコンのアプリで同期すれば扱いやすいのではないか」と考えていました。
また、Google Sparkのような自動実行の仕組みも、
リリースから少し時間が経って今はどのくらい安全に使えるようになっているのか気になっていました。
そこで最初は、世の中の失敗談や、
どういう使い方をすれば不利益が出ないのかという実際の声をAIに調べてもらうことにしました。
自動実行のリスクとローカル環境への切り替え
調べてもらった結果を見ると、やはり自動実行系のツールに広い権限を渡すのはまだ危ないということが分かりました。
・完了したつもりで動いていないことがある: 通知は来るのに実際はシートが更新されていないなど、
動作に不安定な部分が残っている。
・確認フローを飛ばしてしまう不具合: 本来は人間に確認してから送るはずの処理を、
文脈の解釈ミスでそのまま進めようとする報告がある。
・外部からの隠し指示（プロンプトインジェクション）: メールなどを常時監視させていると、
スパムメールの中に書かれた「重要ファイルを転送しろ」という指示に騙されてしまう危険がある。
こうした失敗を防ぐには、メールの送信や既存ファイルの削除・上書きは絶対に許可せず、
「読み取り」と「下書きや新規ファイルへの追記」だけに絞る必要があるとのことでした。
また、データベースをそのままGoogleドライブに置いて同期するとファイルが壊れる原因になりやすいと聞き、
無理にクラウド同期はせず、まずはパソコン内のローカル環境（SQLite）でデータベースを組む方針に切り替えました。
あわせて、GoogleスプレッドシートとAppSheetを使って、
ボタン一つでプロンプトを作れる簡易アプリを最初から用意しておくべきかも聞いてみました。
これについては、AppSheetは後からすでにある表を読み込ませるだけで簡単にアプリ化できる仕組みなので、
扱うモジュールが10個や20個に増えて手作業のコピーが面倒になってから作れば十分だと分かり、
ひとまず後回しにすることにしました。
定額プランの枠内でPythonからAIを動かす方法
次に気になったのが、料金と課金枠の問題です。
以前、PythonのSDKを使って自動化しようとした際、
契約している定額プラン（Google AI Ultra）の枠ではなく、
使った分だけお金がかかる従量課金（API課金）になってしまうことが分かって計画を止めたことがありました。
今の仕様でもそこは変わっていないのか、改めて調べてもらいました。
結果として、やはり現在もSDK経由だとGoogle Cloud側の従量課金が発生してしまう仕組みになっていました。
・CLIやエディタ画面からの利用: ブラウザのアカウント認証を通るため、
定額プランの枠内で追加料金なしに使える。
・Python SDKからの利用: APIキーなどの認証が必要になり、
定額枠とは別に従量課金が発生する。
追加の従量課金は払いたくないけれど、
毎回コマンドを手打ちするのではなくPythonのプログラムで管理したいという希望を伝えたところ、
Pythonのプログラムの中から定額枠のCLIコマンド（`agy`）を呼び出す方法を教えてもらいました。
この形なら定額プランの枠を使いつつ、裏側の処理はPythonで制御できるので、
この方式を採用することにしました。
フックとプログラムが各フォルダに散らばる問題
基本的な動かし方が決まったところで、
今度は「フック（会話の終了時やツールの実行前後に自動でプログラムを動かす仕組み）」と「Pythonのプログラムファイル」をどこに置いて管理するかで悩みました。
フックの設定ファイルは、パソコン全体で効く場所に置く方法と、
プロジェクトのフォルダごとに置く方法の2種類があります。
最初は全体で1つにまとめるのも良さそうに見えましたが、
今後もしデータベースを使わない別の作業をしたくなった時に、
すべてのフォルダで勝手にフックが動いてしまうと困ります。
そのため、フックの設定自体はプロジェクトのフォルダごとに初期設定として置くことにしました。
ただ、ここで2つの疑問が出てきました。
1. 業務ごとにフックの内容をどう切り替えるか: 普通の会話ならログを保存するだけ、
プログラムを書く作業ならテストを走らせる、データベース操作なら危険なコマンドを止める、
といった具合に作業内容によって動かすフックを変えたい。
2. 別のフォルダからどうやってプログラムを動かすか: 今後新しいプロジェクトを別フォルダで立ち上げた時、
実行するPythonファイルがそれぞれのフォルダに分かれていると、
ファイルの書き換え権限を渡したり管理したりするのが面倒になるのではないか。
フォルダには中継機だけ置いて本体はDBに入れる
そこで、「各フォルダには中継機となるファイルだけを1個置いておき、
フックの条件分岐やPythonのコード本体はすべて親フォルダの共通データベースに文字として登録しておくことはできないか」と聞いてみました。
これなら、どのプロジェクトのフォルダで作業していても、
中継機が共通データベースを見に行って必要なコードやフックを引っ張ってくるだけで済みます。
ここで少し心配だったのが、「1つの大きなJSONをデータベースに置くのか、それとも1行ずつ分けて登録するのか」という点と、
「作業のたびに毎回データベースからフックを全部読み込んでいたら動作が重くならないか」という点でした。
AIの回答では、管理のしやすさから見ても1行（1レコード）ずつ独立してデータベースに登録する形が良く、
またSQLiteは非常に高速なので、
10個や20個のデータを毎回読み込んでも0.0002秒（0.2ミリ秒）ほどしかかからないとのことでした。
これなら速度の心配もないので、フックもPythonのコード本体もすべて共通データベースのテーブルに入れておき、
各フォルダの中継機が毎回それを読み込んで動かす設計で作ってもらうことにしました。
実際に動かしてみて出てきた課題と対策
データベースのテーブルと中継機の仕組みを一通り作ってもらったあと、
実際に運用していくうえで気になりそうな点を2つ手直ししました。
1. 指示書を忘れるAIへの文字数制限
AIとのやり取りが長くなってくると、
AI用の指示書ファイルに書いておいたルールをだんだん忘れてしまい、
サブエージェントを作る時のプロンプトに余計な手順まで書き込んで長文化してしまうことがありました。
言葉のルールだけで守らせるのは限界があるので、登録用のプログラム自体を修正し、
コード側で強制的に制限をかける方法をとりました。
具体的には、自由な長文プロンプトの入力を廃止し、
「どういう立場か（最大100文字）」と「何をしてはいけないか（最大150文字）」の2つだけを入力させて、
定型の3行テンプレートに自動合成する仕組みにしました。
文字数を超えるとエラーで止まるので、ルール忘れによる肥大化を物理的に防げるようになりました。
2. 中身が未完成のコードが登録されるのを防ぐ
その後、作った仕組みのテストとして「一次情報の調査」「現場の知見の調査」「批判的な検証」の3つのモジュールを実際に動かしてみました。
定額枠のCLI経由でちゃんと結果が返ってきたのですが、
データベースに保存されたPythonコードの中に、
最後まで処理が書かれていない未完成のものが混ざってしまう可能性に気づきました。
登録する時点で「ちゃんと最後まで動くコードであること」を強制する良い方法がないか調べるため、
さっそく今作ったばかりの調査モジュールと批判検証モジュールを順番に呼び出して、
AI同士で対策を議論してもらいました。
今日わかったことと解決のまとめ
モジュール同士の調査と議論の結果、単にプログラムの文法（構文）が合っているかチェックするだけでは、
中身が空っぽのコードを見抜けないということが分かりました。
最終的に、データベースへプログラムを登録する際は以下の仕組みを組み合わせることで落ち着きました。
・ひな形（テンプレート）の用意: ゼロからコードを書かせず、
CLIの呼び出し処理があらかじめ入ったひな形をベースにする。
・登録時のテスト実行（スモーク実行）: データベースに登録する際、
裏で一度ダミーの引数を与えて実際に動かしてみて、
エラーが出ずに決められた形式で結果が返ってくるかを確認する。
1日目の作業として、最初はクラウド同期やアプリ化などいろいろな構想から入りましたが、
実際に仕組みを調べて相談していく中で、以下のような現実的な形に整理することができました。
・データベースはクラウド同期せずローカルのSQLiteで組む: ファイル破損や自動実行の思わぬ事故を防ぐため、
まずは手元の環境で手堅く動かす。
・定額枠を活かすためにCLIをPythonから呼び出す: SDKの従量課金を避けつつ、
プログラムによる自動化を両立させる。
・実態はデータベースに集約し、フォルダには中継機だけを置く: フックもPythonコードもデータベースのレコードとして1行ずつ管理することで、
今後プロジェクトのフォルダが増えても管理が煩雑にならないようにする。
・AIへのルール付けはプログラムの制限で行う: 指示書に書くだけでなく、
文字数の上限チェックや登録時のテスト実行など、仕組み側でエラーを弾くようにしておく。
まずはこの初期設定をベースにして、少しずつ使えるモジュールを増やしていこうと思います。