はじめに
AIをフル活用した個人開発で macOS 用の Google カレンダークライアントを作り、App Store で公開しました。この記事は「開発におけるAI活用の実例」として、またGoogle OAuthを使用する場合のGoogleの審査の実例について、書いていきたいと思います。
作ったもの
- Galna Calendar — macOS 用の Google カレンダークライアント
- SwiftUIベースのmacOSアプリ。Googleアカウントでログインし、Googleカレンダーを表示するアプリ
- Swift 91 ファイル / 約 15,000 行
- 主な使用ライブラリ：
GoogleSignIn-iOS、google-api-objectivec-client-for-rest（GTLR）、Firebase、StoreKit 2、WeatherKit、CoreData
六曜や天気予報の表示など、機能面ではかなり充実しています。要するに「本気の実装」で、トイアプリではありません。この規模だからこそ審査で色々刺さった、という話でもあります。
テーマはコーディングと審査
書いたコードの半分は私が書き、残りはClude Code（Opusくん）が書いています。この過程で、私は「Vibe Codingは可能だが、プログラミングの知識なしには難しい」という結論に至りました。
審査関連では、Google の OAuth 検証で2回、Apple の App Review で2回、合計4回落ちました。しかもそのうち1回は、機能をひとつ丸ごと削除するという設計判断で対応しています。
同じことをやろうとしている個人開発者向けに、AIコーディングのコツと審査について、詳しく書いておきます。
Claude Code に任せられたこと／任せられなかったこと
まずはAIを使用したコーディングについて。個人的には、このアプリの実装で現状のAIコーディングの最適解に辿り着けたと思っています。
AIに任せたところ
仕様が明確な実装は、ほぼ丸投げできました。以下のような作業はAIに任せると捗ります。
-
人間がするにはシンドイ実装
知ってる人は知っていると思いますが、カレンダーに繰り返しイベントを設定する際には、RRULE:FREQ=WEEKLY;BYDAY=WEのような文字列をパースする必要があります（RFC5545のRRULE）。これがとてもメンドクサイ。。人間がやると3日で心が折れます。AIなら、この手の実装はむしろ得意です。 -
バグの原因調査
AIはバグの原因調査に非常に強いです。「繰り返しイベントを『これ以降すべて』で更新すると失敗することがある」という曖昧な症状から、RRULEのCOUNTとUNTILの併用が RFC 5545 違反で Google に弾かれている、というところまで詰められました。人力だと確実に半日溶けます。
もうひとつ効いたのがコード全体のバグ探索です。「繰り返し処理まわりをスキャンして」と投げると、実際に踏んでいなかった潜在バグが列挙されます。全部が本物ではないので取捨選択は要りますが、当たりの比率は十分実用的でした。
任せられなかったところ
AIに任せられなかったところは、主に以下です。
- UIデザイン
UIデザインは、ほぼ私がコードを書いて作りました。このアプリ、UIデザインも一つ差別化ポイントなので、むしろ私が作るべきですね。 - 設計
UIはSwiftUIかAppKitか、DBはSwiftDataかCoreDataか。また、アーキテクチャはどうするべきか。一般的にはMVVMが最近のスタンダードとされていますが、私は否定的です。
アーキテクチャを決めておき、簡単な実装をしておくことで、AIも実装しやすくなるようです。AIに実力を発揮させるためにも、アーキテクチャを決めて最低限の実装をしておくと良いでしょう。
結論：AIによる実装
このアプリのような、ある程度のどの規模のアプリであれば、Vibe Codingは難しいでしょう。UIデザインと内部の設計はしておく方がスムーズだと思います。
逆に言えば、そこさえ押さえておけば面倒な実装はすべて任せられます。当初、私はAIの書いたコードを目で確認していましたが、やがてそれもやめてしまいました。それほど現代のAIの書くコードの品質は高いです。
さて、次はGoogleとAppleの審査について書いていきましょう。
審査に落ちた① Google OAuth 検証：デモ動画が不十分
Googleアカウントでのログインを実装するには、Googleの審査を受けねばなりません。審査時にそのアプリが使用するGoogleの機能（スコープ）を申請するのですが、スコープによってはsensitiveやrestrictedに指定されており、審査が厳しくなります。
審査には、アプリ自体を提出するのではなく、そのアプリが申請した機能を動かしているところを動画に撮り、アップロードする必要があります。まずはここで審査に落ちました。
アプリの機能がデモ動画で十分に実証されていません。
最初に出した動画は、約6分の無音・無注釈の画面録画でした。全機能は映っていたのに落ちています。
原因は、審査担当が**「どのシーンがどのスコープの実証なのか特定できない」**ことでした。Google のガイドは動画に対して次を求めています。
- OAuth 同意フロー全体（サインイン開始 → 同意画面 → 許可）が映っていること
- 同意画面に申請スコープが表示され、言語を English にしてあること
- 申請した全スコープについて、実際に使われている箇所が映っていること
- ナレーションや注釈で、要件をどこで満たしているか明示すること
対応
動画を撮り直さず、各シーンに英語のテロップを焼き込みました。修正は、GoogleのメッセージをAIに見せて、そのまま丸投げしています。
教訓：デモ動画は「機能が映っていること」ではなく、**「審査担当が確認作業をできること」**が要件です。無音の画面録画は、要件を満たしていても落ちます。
審査に落ちた② Google OAuth 検証：プライバシーポリシーのデータ保護開示
動画を直したら、次はこれでした。
貴社のプライバシーポリシーには、機密データに対するデータ保護の仕組みが明記されていません。
審査では、プライバシーポリシーの中身も詳しく確認されます。英語版も必要です。使用すスコープによって、必要な条文が決まっているのです。この場合、私のアプリがsensitive指定のスコープを使用していたため、このような指摘を受けました。
ただ、AIがあればこの修正も大幅に楽になります。
対応
「データ保護のための安全管理措置」という条項を新設し、具体的な機構を列挙しました。ほぼAIに条文は書かせ、人間が確認しています。
教訓：sensitive スコープを使うなら、ポリシーにセキュリティの実装内容を書く必要があります。「安全に扱います」では通りません。
審査に落ちた③ …の前に：CASA を回避するため、機能をひとつ捨てた
これは「落ちた」というより、落ちる未来が見えたので先に構成を変えた話です。
Google から、こういう通知が来ました。
2026年10月25日までに、アプリケーションのADA-CASA AL1セキュリティ評価を完了する必要があります。
**CASA（Cloud Application Security Assessment）**は、App Defense Alliance が運営するセキュリティ評価です。restricted スコープを使うアプリは、これを毎年受けることが義務になります。
- 認定ラボ（TAC Security、Bishop Fox、NCC Group など世界に9社のみ）に依頼する
- 期間は2〜6週間
- 毎年更新
おぉ。。これはもう、個人開発には厳しい領域です。Googleが指定する9社のどれかに、毎年、審査してもらえですと？調べると1回数十万円かかるんですけど？？
私が使っていた restricted スコープは drive.readonly ひとつだけでした。これを削除し、泣く泣く機能も削除することにしました。
審査に落ちた④ Apple 2.1(a)：Google ログインのアプリで、デモアカウントが通らない
さて、そんなこんなでGoogle 側の審査を通し、いよいよ Appleの審査です。個人的にはAppleの審査には慣れており、落ちたとしても「まぁ大丈夫でしょ」的な見通しはありました。
審査に出したら、これで落ちました。
in addition to the demo account username and password you provided, we need an authentication code to access the app's content
デモ用の Google アカウントの ID とパスワードは Review Notes に書いていました。それでも足りません。
原因は、Apple のレビュー端末は米国にあり、Google がそれを「見慣れないデバイス」と判定して確認コードを要求するためです。コードは私の端末に届くので、レビュアーは永久に受け取れません。
Apple 側は3つの回避策を提示していました。
- デモアカウントのコード検証をバイパスする
- 固定の認証コードを設定する
- 全機能を確認できるデモモードを実装する
Google 認証を使っている以上、1と2は不可能です。（2段階認証を切っても、Google のリスク判定は制御できません）
対応：デモモードの実装
3を選びました。これもClaude Codeに任せて約1時間で実装完了。すごい。
落ちた⑤ Apple 5.2.5：WeatherKit の帰属表示
デモモードを入れて再提出したら、今度はこれでした。
そのアプリはWeatherKitに対応しているようですが、WeatherKitのクレジット表示（アトリビューション）に関する要件を遵守しているかどうかを確認する必要があります。
カレンダーの日付欄に天気アイコンを出すのに WeatherKit を使っていました。WeatherKit を使うアプリは、Apple Weather の商標とデータソースへのリンクを表示する義務があります。完全に見落としていました。
対応
UIにそのような表示を入れる。Claudeに頼んで10分で完了。
教訓：WeatherKit は追加したその日に帰属表示も入れるべきです。実装は10分ですが、忘れると審査1往復（数日）を失います。同種の要件は MapKit などにもあるので、Apple のフレームワークを足すときは利用条件を先に読むのが結局速いです。
おわりに
実装は Claude Code のおかげで驚くほど速く進みました。ですが、それはUI設計、内部アーキテクチャ設計ができていればこそです。まずは設計を固めておかないと、AIによる実装も何度もやり直すことになります。
審査についても、審査に伴う修正をAIに任せることで、これも爆速で進めることが可能です。以前はプライバシーポリシーの改訂に2週間かかっていたものが、AIだと10分です。これは驚異的。
他方、CASA対応を回避するために機能を削除したりする判断は、人間にしかできません。適切な判断ができる知識は必要です。
この開発を通して得た知見は、ちまたでVibe Codingやエンジニアがギュられる（失職する）ことが話題となる中、エンジニアが生き残る道を示すものでもあると考えています。現状、AIのみでは実用レベルのアプリを作ることは難しいと思いますが、AIがあれば生産性が爆上がりすることも事実です。人間とAIの協働が大切です。
この記事が何かのお役に立てば幸いです。
この記事で触れた実装は、拙作 Galna Calendar（macOS 用 Google カレンダークライアント）のものです。空き時間の自動調整や Meet URL の発行に対応しています。