Gemini CLIをiOSアプリ開発に1週間使い続けて分かったこと

Xcodeを開いていたとき、ふとある記憶が浮かびました。宮大工だった祖父が「手を動かすことが一つの信心だ」とよく言っていたことです。ツールへの向き合い方が、その人の仕事への姿勢そのものだと、今になって思います。

2014年からiOSとAndroidアプリの個人開発を続けてきました。累計ダウンロード数が5,000万を超えた現在も、企画からリリースまで基本的には一人でこなしています。その分、新しいツールを導入するときは慎重にならざるを得ません。流行に乗って何でも試していたら、コアな開発時間が削られてしまいます。

それでも、Gemini CLIについては「1週間だけ試してみよう」と決めました。この記事は、その実録です。

Gemini CLIをiOS開発に試そうと思ったきっかけ

Gemini CLIはターミナルから直接Geminiモデルと対話できるツールです。geminiコマンドに続けてプロンプトを書くか、パイプでファイルの内容を渡す形で使います。

試そうと思った理由は3つあります。

まず、コスト面での気軽さです。GeminiにはGoogleアカウントで使える無料枠があり、個人開発の実験的な用途であれば課金なしで試せます。次に、テキスト変換系のタスクに向いていそうだという直感がありました。翻訳・リライト・リリースノート生成など、CLIから手軽に呼べると開発フローに自然に組み込めそうです。最後に、Claude Codeとの使い分けを自分で検証したいという興味もありました。

私のiOSアプリ開発で特に手間がかかる作業として、以下を感じていました。

App Storeのリリースノートを日本語と英語で書くこと
Localizable.stringsの多言語対応（200エントリー超のアプリもあります）
ユニットテストの雛形を用意すること

これらをGemini CLIで省力化できるかを、1週間かけて検証しました。

セットアップ：5分でターミナルから使えるようになる

インストールはnpm経由が最も手軽です。

npm install -g @google/gemini-cli
gemini auth

gemini authを実行するとブラウザが開き、Googleアカウントでの認証が求められます。認証後はターミナルに戻るとすぐに使い始めることができます。

初回実行後、~/.gemini/config.jsonに設定ファイルが作られます。モデルの指定（gemini-2.5-proやgemini-2.5-flash）もここで変更可能です。

# 動作確認
echo "Hello, Gemini" | gemini

これだけでセットアップは完了です。驚くほどシンプルでした。

実際に試した5つのユースケース

① Swiftコードレビュー

ViewControllerやServiceクラスのファイルを渡してレビューを依頼しました。

cat NetworkManager.swift | gemini "このSwiftコードをレビューして、メモリリークのリスクがあれば指摘してください"

単一ファイルのレビューは概ね機能しました。weak selfの漏れやNotificationCenterの解放忘れを指摘してもらえた場面もありました。ただし、プロジェクト全体の設計を知らないため、「別クラスに責務を移した方がよい」という提案が、すでに別ファイルに実装済みだったこともあります。コンテキストの限界を感じる瞬間でした。

② XCTestのユニットテスト生成

関数のシグネチャを渡してテストの雛形を生成させました。

cat UserService.swift | gemini "このServiceクラスに対するXCTestのユニットテストを生成してください。モックはprotocolベースで作ってください"

生成されたテストコードの70%程度はそのまま使えるクオリティでした。XCTestExpectationの使い方は正確で、基本的なパターンは良好です。ゼロから書くよりも明らかに速く、雛形として活用できます。

③ Localizable.stringsの翻訳補助

多言語対応の翻訳作業に使いました。

cat ja.lproj/Localizable.strings | gemini \
  "このLocalizable.stringsを英語に翻訳してください。iOSアプリのUIテキストとして自然な英語にしてください"

この用途で最も効果を感じました。直訳感が少なく、UIテキストとして違和感のない英語が出てきました。私のアプリでは約200エントリーの翻訳が通常2〜3時間かかるところ、下訳として活用することで30分程度に短縮できました。

ただし、アプリ固有の固有名詞（機能名など）については確認が必要です。そこは省略しない方が安全です。

④ リリースノートの自動生成

gitのコミットログをApp Storeのリリースノートに変換させました。

git log --oneline v2.1.0..HEAD | gemini \
  "これらのコミットをApp Storeのリリースノートとして整形してください。技術的な表現をユーザー向けの言葉に変えて、日本語と英語の両方で書いてください"

コミットメッセージの技術的な表現をユーザー向けに変換してくれます。「Fix: crash when loading large images」が「大きな画像を読み込む際のクラッシュを修正しました」になるような変換です。実際に使えるクオリティで出てくることが多く、この用途は想定以上でした。

⑤ ビルドエラーの解析

Xcodeのビルドエラーを貼り付けて原因を聞く使い方です。

gemini "以下のXcodeビルドエラーの原因と解決策を教えてください：
error: Build input file cannot be found: '/Users/xxx/Project/Framework.framework'
Target 'MyApp' (project 'MyApp')"

一般的なエラーパターン（Frameworkの参照切れ、Swiftのバージョン非互換など）は対応できます。ただし、プロジェクト固有の設定ファイル（xcconfig、Podfile.lock）が絡む場合は、「設定ファイルを見せてください」という返答になることが多く、CLIの限界を感じました。

特に効果を感じた場面：翻訳とリリースノートの組み合わせ

1週間の中で最も「これは使える」と感じたのは、翻訳とリリースノート生成の組み合わせです。

アプリのアップデート時に、日本語の変更内容を確定した後、そのままCLIで英語版を生成し、軽く校正するというフローができました。従来は「日本語で書く → 英語で書き直す」という作業が独立していましたが、これが一続きになったことで、リリース作業全体のテンポが上がりました。

うまくいかなかった場面（正直に）

プロジェクト全体の文脈を渡せない

CLIでは1回のコマンドで渡せる情報に限りがあります。10ファイル以上にまたがる設計レビューや、依存関係が複雑なリファクタリング提案には向きません。

大きなSwiftファイルの処理

2,000行を超えるViewControllerを丸ごと渡すと、コンテキスト上限に引っかかることがありました。分割して渡す工夫が必要です。

応答速度のばらつき

日本時間の日中は応答が遅い傾向がありました。早朝や深夜の方がストレスなく使えます。Googleのインフラ側の問題であるため、時間帯を選ぶことで対処できます。

Claude Codeとの使い分けについて

Gemini CLIとClaude Codeを比べると、競合するというよりも得意領域が異なります。

Gemini CLIが向いているタスク:

テキスト変換（翻訳・リライト・要約）
リリースノート生成
単一ファイルのクイックレビュー
無料枠での実験的な用途

Claude Codeが向いているタスク:

プロジェクト全体を把握した上でのリファクタリング
マルチファイルにまたがる設計提案
長期的なコーディングセッション

コスト面でも違いがあります。Gemini CLIはGoogleの無料枠が広く、実験的な用途では課金なしで試しやすいです。Claude Codeはより高度なコンテキスト管理が強みですが、利用量に応じたコストがかかります。

どちらが優れているかではなく、タスクの性質に合わせて選ぶというのが、1週間使ってみた現時点での結論です。

まず試してほしいユースケース

Gemini CLIをまだ試したことがない方は、App Storeのリリースノート生成から始めてみることをお勧めします。git log --onelineの出力を渡すだけで、すぐに使えるテキストが返ってきます。

最初の体験として手応えを感じやすく、開発フローへの組み込み方も自然にイメージできるはずです。その後、翻訳補助 → コードレビューの順で活用範囲を広げていくと、無理なくワークフローに組み込めると思います。

個人開発者として 12 年見てきたツール選びの基準

新しい AI ツールを採用する時、私は 3 つの軸で評価しています。初期セットアップの早さ・ロックインの薄さ・コミュニティの活発さです。Gemini API はこの 3 軸どれもバランスが良く、特に Google Workspace との連携が強いところが、私のような個人開発者にはありがたい設計だと感じます。

NTT DATA で基幹システムの SE をしていた 2002 年頃と比べると、信じられないスピードで AI ツールが進化していますが、選定基準は変わりません。長く使える土台を作ることが、結局は一番の近道だと考えています。