実施日: 2026-06-21
実装案 v2 に対する Claude review の高位指摘を、見解ではなく実機結果と公式契約で判定する。
対象:
同じ実ユーザーcredentialを複製したProject Alpha / BetaのHOMEで、expiry_date=0 にしてagyを同時起動した。
結果:
NO_TOOL_CALL / fullyIdle=true。この結果だけではrefreshが起きたことを証明できない。
複製側だけ access_token=FORCED_INVALID_ACCESS_TOKEN、expiry_date=0 とし、有効なrefresh tokenを残して2 HOMEを同時起動した。
結果:
agyがproject HOME内のOAuth JSONを認証の正本にしていない可能性が高い。
両project HOMEから oauth_creds.json と google_accounts.json を外し、設定・hook・空workspaceだけを残して同時起動した。
結果:
| 項目 | Project Alpha | Project Beta |
|---|---|---|
| exit code | 0 | 0 |
| 所要時間 | 8秒 | 8秒 |
| stdout | KEYRING_ALPHA_OK |
KEYRING_BETA_OK |
| stderr | 0 byte | 0 byte |
| termination | NO_TOOL_CALL |
NO_TOOL_CALL |
| fullyIdle | true | true |
conversation IDは別々で、各transcriptは各project HOME配下に保存された。
このLinux実環境では、agy認証は公式説明どおりOS keyringから取得される。project HOMEへOAuth JSONを複製する必要はない。
したがって、Claude review #1の「複製したrefresh token同士がrotationで無効化し合う」リスクは、採用構成には存在しない。project HOMEは認証境界ではなく、設定・hook・conversation・transcriptの分離境界とする。
実装ではcredentialをproject stateへ複製しない。keyringで認証を取得できなければ auth_required とし、対話ログインを案内する。
参考:
公式Plansはrate limitがGoogle AI planとアカウント利用量に依存し、使用量がagentの作業量によって変動するとしている。複数project HOMEも同じOS keyringアカウントを使うため、quotaはproject別には分離されない。
2project同時実行が繰り返し成功することは確認したが、quota枯渇を意図的に起こす試験は追加費用・サービス影響があるため実施しない。
判定:
参考:
sandbox有効agyを専用process groupで起動し、SIGTERM後にagy / agentapi / nsjailの新規PIDが残らないことを確認するprobeを準備した。
ただし実行時、外部実行承認基盤の利用上限によりコマンドが拒否された。安全ポリシーに従い迂回実行していない。
判定:
command(*) をdenyするためagent起因の任意子processは作らないが、agy自身のagentapi / sandbox processを外側deadlineで停止できることは別途実証が必要。公式Hooks仕様で公開されているもの:
conversationIdtranscriptPathterminationReasonfullyIdleerror公式文書はtranscriptをpersistent JSONL logとして案内している。一方、JSONL内部の source=MODEL / type=PLANNER_RESPONSE / status=DONE は公開schemaとして確認できない。
今回の正常実行6件では、全件でStop event、fullyIdle=true、個別conversation ID、project HOME配下のtranscriptを取得できた。従来probeの早期timeoutではStop hookが発火しなかった。
判定:
参考:
Phase Aのfixture / parser / command builder実装を止める理由はない。Phase Bでproduction routeを有効化する前にprocess tree停止probeを完了する。