Gemini CLIに全部を任せない：定型処理をコード化し、判断だけをAIに渡す業務改善

先に判断したい方へ：入力形式や重複排除のようにルールで決まる処理は通常のコードに残し、文章の分類・要約など正解が一つに決まらない処理だけをGemini CLIへ渡します。送信・削除・支払いなど取り消しにくい操作は、この構成の対象外です。

まず結論：Gemini CLIには「判断」だけを任せる

Gemini CLIは、Geminiをターミナルから使い、ファイル操作やシェル実行などのツールも呼べるオープンソースのAIエージェントだ。けれど、業務改善での扱い方は「店を丸ごと任せる店長」より、伝票を見て“要確認かどうか”を判定するベテラン係に近い。入力収集、形式検査、重複排除、保存、通知は普通のプログラムに任せ、文章の意味を読む部分だけGeminiへ渡すのである。

これでできるのは、問い合わせの振り分け、議事録からの論点抽出、差分レビュー、障害ログの一次分類、規程との意味的な照合などだ。大事なのは、AIが返した答えをそのまま確定処理にせず、検証可能な中間データとして受け取ることだ。

導入前に比べる5つの項目

「他サービスより性能が低い／高い」と一行で順位を付けたくなるが、その比較はかなり危うい。モデル、プロンプト、ツール、制限時間、リポジトリ、採点者が変われば結果も変わるからだ。コーディングベンチマークの点数と、社内メールの分類精度は、100メートル走と荷物運びほど別競技である。

見る軸	確認する質問	社内評価の例
判断品質	誤判定の種類は何か	過去100件を人手の正解と照合
再現性	同じ入力で結論が揺れるか	同一セットを複数回実行
運用品質	失敗を検出して再実行できるか	終了コード・JSON・監査ログを確認
安全性	触れてよいファイルとコマンドを絞れるか	拒否ルールをテスト
費用・待ち時間	繁忙時にも許容範囲か	自社入力で計測

Gemini CLI自体にも、長い自律実行を完全に任せるハーネス（モデルに道具、状態管理、権限制御、再試行を与える実行基盤）として注意点がある。公式のヘッドレス実行リファレンスにはターン上限超過を表す終了コード53があり、ポリシーエンジンの説明では、非対話実行で確認できない ask_user は拒否扱いになり、Workspace階層のポリシーは無効と警告されている（2026年9月22日確認）。これは欠陥をあげつらう話ではない。仕様が変わる可能性も含め、止まる前提で外側のプログラムを設計する理由だ。

定型処理とAI判断を分ける

料理でいえば、計量、加熱時間、在庫更新まで料理人の勘に任せない。レシピとタイマーで固定し、「香りを見て火を止める」のような曖昧な判断だけを人、今回はGeminiに渡す。この分離なら、モデルが不得意な日でも被害範囲を限定できる。

この仮説のポイントは、AIの出力を「文章」ではなく契約として扱うことだ。ただし --output-format json が保証するのはCLI外枠のJSONであり、response は文字列である。内側の業務JSONまで自動的に正しいとは限らない。そこで外側を jq で取り出し、もう一度スキーマ検査する。

公式仕様から確認できること

公式文書を機能ごとに読むと、短い判定部品として使う材料はそろっている。-p による一回実行、標準入力、json またはストリーミングJSON、標準終了コードがある。サンドボックスはホストから操作を隔離でき、ポリシーエンジンはツールを許可・拒否・確認に振り分けられる。ただし、ここに挙げる機能名や挙動は更新され得るため、導入時は末尾の公式文書で利用中のバージョンを確認してほしい。

責務	Geminiへ渡すか	理由
CSV読込、必須列、日付形式	渡さない	ルールで一意に判定できる
自由記述の緊急度	渡す	文脈と含意を読む必要がある
顧客への送信、削除、振込	直接は渡さない	不可逆または影響が大きい
結果のJSON検証、重複排除	渡さない	機械的に保証できる
最終承認	人へ返す	責任と例外判断を残す

一方、サンドボックスを有効にしただけで安全が完成するわけではない。公式説明では、コンテナ方式でも現在の作業ディレクトリは同じ絶対パスでマウントされる。つまり作業ディレクトリ内の変更は起こり得る。信頼フォルダ機能も既定では無効であり、フックはユーザー権限で任意コードを動かす。砂場には柵があるが、砂場の中のお城は壊せる、と覚えておこう。

コピーして試せる最小構成

まずは「問い合わせ文を normal / review に分類し、理由を添える」だけに絞る。次の例はファイル編集やシェル実行をGeminiへ頼まず、標準入力から判断だけを受け取る。結果ファイルは一時ファイルから原子的に置き換えるため、途中失敗で半端なJSONを残しにくく、同じ入力なら何度でもやり直せる。

#!/usr/bin/env bash
set -euo pipefail

input=${1:?"usage: classify.sh INPUT.txt"}
out_dir=${OUT_DIR:-results}
mkdir -p -- "$out_dir"

# 大きさと空入力を、モデルを呼ぶ前に決定論的に拒否する。
test -s "$input"
test "$(wc -c < "$input")" -le 20000

outer=$(mktemp)
inner=$(mktemp)
trap 'rm -f "$outer" "$inner"' EXIT

prompt='問い合わせを分類してください。返答は説明やコードフェンスを付けず、
{"label":"normal または review","reason":"80文字以内"}
というJSONオブジェクトだけにしてください。送信・更新・削除はしないでください。'

gemini -p "$prompt" --output-format json < "$input" > "$outer"
jq -er '.response | fromjson' "$outer" > "$inner"
jq -e '
  type == "object" and
  (.label == "normal" or .label == "review") and
  (.reason | type == "string" and length <= 80) and
  (keys | sort == ["label", "reason"])
' "$inner" >/dev/null

target="$out_dir/$(basename "$input").json"
tmp_target=$(mktemp "$out_dir/.result.XXXXXX")
cp -- "$inner" "$tmp_target"
mv -f -- "$tmp_target" "$target"
printf '%s\n' "$target"

ここで set -euo pipefail と jq -e が重要だ。Geminiが気の利いた前置きを足したり、未知のラベルを返したりしたら、静かに確定するのではなく処理を失敗させる。モデルの機嫌をコードで受け止める、いわば業務用の受け身である。

どの業務に向いているか

派手な自律エージェントより、小さな「意味判定API」として考えると候補が一気に増える。以下は導入候補であり、削減率を保証する実績値ではない。各社のデータで、誤検知と見逃しを別々に計測してほしい。

現場の悩み	コードが担当	Geminiが担当	人が担当
問い合わせが混ざる	受信、個人情報マスク、重複排除	カテゴリと緊急度の候補	高リスク案件の確定
議事録が読まれない	文字起こしの分割、参加者照合	決定・宿題・未決事項の抽出	担当者と期限の承認
日報が大量にある	日付検査、欠損検出、集計	共通する阻害要因の要約	対策の優先順位付け
PRレビューが滞る	diff取得、lint、test	意図との不一致候補を説明	マージ判断
障害ログが長い	時刻整列、既知エラー照合	未知パターンの仮説生成	復旧操作と事後判定
規程確認に時間がかかる	版管理、条項番号の照合	申請文と条項の意味的な関連付け	法務・管理者の承認

たとえばサポート担当の朝を想像しよう。コードが夜間の問い合わせを集め、既知の注文番号を照合し、個人情報を伏せる。Geminiは自由記述だけを読み「返金の可能性」「安全上の懸念」を候補化する。担当者は review の箱から見る。Geminiが顧客へ勝手に返信しないので、誤判定は作業順の候補に留まり、事故へ直結しにくい。

なお、公式の自動化チュートリアルにも、ログ説明、git diff からのコミットメッセージ、複数ファイルの文書化、JSON抽出が例示されている。最初はこのような「読んで下書きする」仕事から始めるのが堅い。

再試行・監査・承認は外側で設計する

Gemini CLIにはポリシー、サンドボックス、チェックポイント、フック、拡張がある。それでも、業務固有の再試行、入力の一意性、二重実行防止、承認責任、品質指標まで自動で設計してくれるわけではない。高性能な包丁に、厨房の衛生手順までは付いてこないのと同じだ。

この設計にはもう一つ利点がある。Geminiの性能がタスクに合わなければ、判断部品だけ別モデルや人手へ差し替えられる。比較すべきはブランドではなく、固定した自社の正解データに対する品質、失敗率、所要時間、費用だ。特に見逃しが重大な業務では、全体の正解率だけでなく「重大案件を見逃した件数」を独立した停止基準にする。

通常コード・他のAI・人手との使い分け

競合CLIを含むエージェント製品は更新が速く、同名機能でも挙動が違う。そのため、ここでは根拠の薄い総合順位ではなく、選定時に固定すべき条件を比べる。

方式	強み	弱み	向く仕事
通常のPython／シェル	再現性、速度、テスト容易性	曖昧な文章判断が苦手	収集、変換、検証、保存
Gemini CLIを判定部品化	自然言語判断と既存CLIの接続	出力揺れ、API依存、検証が必要	分類、抽出、下書き、説明
他社のCLIエージェント	モデルや統合、承認UXが用途に合う場合がある	同じく自社評価と安全設計が必要	固定評価セットで優位だった工程
人手のみ	例外責任、暗黙知、対人配慮	大量反復と待ち時間	不可逆な承認、少数の難案件

まず候補を同じ入力、同じ出力契約、同じ時間上限で走らせる。次に「正解」「要レビュー」「危険な誤答」の三段階で採点する。性能差が出たら、その条件と日付を添えて記録する。これなら「Geminiは全部弱い」とも「全部強い」とも言わず、目の前の業務に対して誠実に選べる。

よくある失敗と対処

導入で怖いのは、エラーが出ることより、間違ったまま成功扱いになることだ。ここでは症状、原因、対処をセットで見ていこう。

症状	原因	対処
JSONの前に説明文が付く	業務JSONは単なる応答文字列	`fromjson` とキー・型・値の許可リストで拒否
CIで確認待ち／拒否になる	非対話環境では `ask_user` が拒否扱い	読取専用に絞り、必要な操作だけ明示的に許可
サンドボックスなのにファイルが変わる	作業ディレクトリはマウント対象	使い捨てコピー、最小権限、差分確認を併用
プロジェクトのポリシーが効かない	公式文書上、Workspace tierは現在無効	User/Adminポリシーを使い、拒否テストをCI前に実施
フックで情報漏えいする	フックはユーザー権限の任意コード	出所をレビューし、秘密を環境から外し、信頼フォルダを有効化
同じ案件を二度処理する	モデルで重複管理まで行う	入力ハッシュや業務IDをDB側の一意キーにする

チェックポイントは便利だが既定では無効で、設定から有効化する。しかも、これはAIによるファイル変更前のスナップショットであり、外部サービスへの送信やDB更新を巻き戻す万能タイムマシンではない。不可逆操作は最後まで人の承認後に置こう。

導入手順：小さく試して評価する

いきなり全社メールを自動送信する必要はない。まず一つのフォルダ、一つの判定、一人の確認者から始める。小さく始めるのは弱気ではなく、評価データを作る最短ルートだ。

時期	やること	合格条件
今日	CLIを起動し、匿名化した1件をヘッドレスで分類	JSON検証失敗時に保存されない
今週	過去の正解付きデータで影運用	危険な誤答を個別に確認できる
今月	読取専用の本番フローへ接続	監査ログ、停止手順、担当者、費用上限が決まる

今日の最小アクションは公式の案内どおり、Node.js環境で次を試すことだ。

npx @google/gemini-cli

自動処理は対話画面ではなく、匿名化済みのテキストで始める。

printf '%s\n' '配送予定を過ぎています。確認してください。' \
  | gemini -p '緊急確認が必要か、理由とともに短く判定してください' \
      --output-format json \
  | jq -e '.response | type == "string"'

今週は50件や100件など、自社でレビューできる規模の評価セットを作る（件数そのものに魔法はない）。入力、期待値、実出力、モデル、CLI版、実行日時を保存する。今月は、タイムアウト、再試行上限、費用上限、停止スイッチ、個人情報の扱いを決めてから本番へ進む。書き込みが必要なら、ポリシーとサンドボックスを足してもなお、人の承認を最後に残す。

要点まとめ

最後に、設計会議へ持ち帰れる形に圧縮しよう。主語はGeminiではなく、あくまで業務フローである。

固定する	収集、形式、重複、保存、再試行は通常コードで決める
任せる	自由記述の分類・抽出・説明など曖昧な判断だけを渡す
疑う	CLIのJSON外枠と、モデルが返す業務JSONを二段階で検証する
閉じ込める	ポリシー、サンドボックス、信頼フォルダに加え、使い捨て環境を使う
測る	他サービスとの総合順位ではなく、自社データの危険な誤答を測る
残す	送信・削除・支払いなど不可逆な決定は人が承認する

Gemini CLIは、すべてを任せるには揺らぎも運用上の注意もある。しかし「だから使えない」ではない。定型部分を決定論的なプログラムで固め、意味を読む一工程だけを切り出せば、活用先は問い合わせ、議事録、レビュー、ログ、規程確認へ広がる。これを読んだあなたは、AIを万能社員に見立てず、交換可能で検証可能な判断部品として業務へ組み込める。

参考文献

以下は2026年9月22日に確認した一次情報である。更新の速いプロジェクトなので、導入時にはリンク先の現行仕様も確認してほしい。

Rui Software

黙り虫、壁を破る