Share
Embed
Gemini CLIでもセキュアで堅牢な開発をしたい!
Yunosuke Yamada
October 19, 2025
Transcript
30 slides
-
Gemini CLIでもセキュアで堅牢な開発をしたい! クラウドネイティブ × Gemini CLI 株式会社スリーシェイク 山田悠之介 2025/10/20 Copyright
© 3-shake, Inc. All Rights Reserved. -
自己紹介 • Webアプリケーションの内製化支援、 生成AIの導入支援をしています • Gemini CLIは ◦ 普段の業務で使ってる ◦
プレビュー版を使ってる ◦ stableとpreviewのリリースノートを 追っている って感じです 2 -
3つの認証方法、7つのプラン 1. Googleログイン a. 無料:Gemini Code Assist for individuals b.
有料:Google AI Pro/Ultra、Gemini Code Assist Standard/Enterprise edition 2. Gemini APIキー a. 無料:Unpaid b. 有料:Paid 3. Vertex AI a. 無料:Express Mode b. 有料:Regular Mode 3つあること、それぞれ有料・無料があることだけ押さえてください! 8 -
監査ログ Gemini CLIにおける監査ログは • Google Cloudのデータアクセス監査ログ • いつ、誰が(どのプリンシパルが)、何をしたか(どのAPIを実行したか)を記録 監査ログはGemini Code
AssistとVertex AIで利用時に出る Gemini APIキーで利用時は出ない 10 -
結論 以上を踏まえてどちらかを使う ① Gemini Code Assist Standard/Enterprise edition ② Vertex
AI (Regular Mode) ①は定額でおすすめ、ただしクォータ制限あり、モデル指定不可 ②は従量課金、個人のクォータ制限なし、モデル指定可能 11 -
テレメトリ 監査ログはGoogle CloudのAPIを叩いたときだけ出る ツール実行時には出ないので、テレメトリ設定の有効化が必要 Google Cloudに直接エクスポートの場合には以下を設定 • settings.json • Google
Cloudの権限(Cloud Trace Agent、Logs Writer、Monitoring Metric Writer) 取得できる項目はドキュメントを参照 12 { "telemetry": { "enabled": true, "target": "gcp" } } -
settings.jsonの優先順位 4種類の配置場所があり、後のものほど高優先度 1. システムデフォルト 2. ユーザ設定(~/.gemini/settings.json) 3. ワークスペース設定(<project>/.gemini/settings.json) 4. システムオーバーライド(Linuxなら/etc/gemini-cli/settings.json)
システムオーバーライドの書き込み権限を一般ユーザに与えなければ、 管理者がGemini CLIの設定をコントロールできる 14 -
settings.jsonのマージ 重複する設定があった場合のマージ戦略は設定項目によって異なる • SHALLOW_MERGE:オブジェクトに対して浅いマージをする ◦ キー名が同じ場合は高優先度で上書き ◦ 該当する設定:mcpServers • CONCAT:単純な結合
◦ 該当する設定:context.includeDirectories • UNION:重複を排除して結合 ◦ 該当する設定:tools.exclude、advanced.excludedEnvVars、extensions.disabled、 extensions.workspacesWithMigrationNudge • REPLACE:高優先度で上書き ◦ 該当する設定:残り全て 例えば先ほど見たtelemetryはREPLACEなので一般ユーザが変更できない 15 -
認証方法の統制 security.auth.enforcedTypeをシステムオーバーライドで設定することで、 一般ユーザがGemini CLIを利用する際の認証方法を強制できる 異なる認証方法を使った場合はGemini CLIを使用できない 18 { "security": {
"auth": { "enforcedType": "vertex-ai" } } } -
サンドボックス 意図しない開発環境の変更や危険な操作の影響を減らすため、サンドボックスを利用する 以下をサポート • Docker • Podman • sandbox-exec ※ローカルでもアプリをコンテナとして動かしている場合
• アプリコンテナをサンドボックスで実行するためにはサンドボックスコンテナを 特権モードで実行する必要があり本末転倒 • サンドボックスではなくGitHub CodespacesやCloud Workstationsなどの クラウド開発環境を利用する 20 -
サンドボックスのカスタマイズ(Dockerの場合) Gemini CLIに実行させたいコマンドをインストールしたカスタムイメージを作成する • ベースイメージ:us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox ◦ タグはバージョンと同じ • 配置場所:.gemini/sandbox.Dockerfile •
ビルド:docker build -t gemini-cli-sandbox -f .gemini/sandbox.Dockerfile .gemini • 設定 • 起動:gemini --sandbox-image gemini-cli-sandbox 21 { "tools": { "sandbox": "docker" } } -
安全なツールを自動承認する サンドボックスで実行するだけでは、外部環境を変更する可能性のあるコマンドには無防備 • 例えばcurl、wget、git push、docker push、kubectl apply、terraform apply 起動オプションで--approval-modeを指定するとある程度コントロール可能 •
default:読み取り専用ツールのみ自動承認される。 編集ツールは承認が必要なので非効率。 • yolo:全てのツールが承認なしで実行される。非推奨。 • auto_edit:読み取り専用ツール、編集ツール、web_fetchが自動承認される。 run_shell_commandは承認が必要なので、安全なものはtools.allowedで指定する。 バランスが良いので推奨。 23 -
安全なツールを自動承認する tools.allowed:設定されたツールの実行を自動承認する --approval-modeとの兼ね合いでシェルツールを指定すると良い ※uv runやbun runなど任意のコマンドを実行可能なコマンドは、制限して許可すること 24 { "tools": {
"allowec": [ "ShellTool(uv run ruff)", "ShellTool(uv run mypy)", "ShellTool(uv run pyright)", "ShellTool(uv run pytest)" ] } } -
仕様駆動開発 1セッションで高品質なアウトプットはできない 仕様駆動開発でマネジメントしてあげる • Spec Kit ◦ GitHub製、技術選定もドキュメントに残る ◦ 英語のみ対応、カスタムコマンド打つのが面倒かも
• Spec Workflow MCP ◦ 日本語対応、コマンド不要で体験が良い ◦ 個人開発 • cc-sdd ◦ 日本語対応、Kiro互換、成果物が日本企業に合っている ◦ 個人開発、カスタムコマンド打つのが面倒かも 26 -
仕様駆動開発 所感 • 合うものを使えば良い ◦ 例)開発元が信頼できるのでSpec Kit ◦ 例)(カスタムコマンドを精査した上で)成果物が既存プロセスにあっているので cc-sdd
◦ 例)そういうのは良いから体験が良いSpec Workflow MCPにする • 日本語対応は重要ではないかも ◦ 日本語対応を謳っていても英語で出してくることもある ◦ 英語で出してきたら日本語でやり直させるだけ • 縛れるのは仕様、設計、計画の部分のみ ◦ コードレベルでは何も縛っていないので、 小さいステップで実装させてレビューする必要がある 27 -
About Us ————— Mission インフラをシンプルにして イノベーションが起こりやすい世界を作る ————— Vision 労苦〈Toil〉を無くすサービスを 適正な価格で提供し続ける ————— Services 30
インフラのプロフェッショナルパートナー アプリケーション層の セキュリティーをフルカバー データ統合プラットフォーム エンジニア組織特化型HRパートナー テックブログやってます! エンジニア超採用中です!