何を作ろうとしたか#

前提を少しだけ。個人でのアプリ開発は、これが二作目だった。一作目は横書きの日本語サイトを縦組みに変換して読む縦書きブラウザ tanzaku で、こちらは無事 Play ストアにリリースできている。tanzaku は Drive のような重い権限を触らないので、公開まで大きくは詰まらなかった。その第二弾として、今度は Drive 連携に踏み込んで作っていたのが bonsai だ。

bonsai は、自分の Google Drive に散らばった Markdown を、スマホで自然に読める・書けるビューア兼エディタだ。

動機はシンプルで、Drive アプリや Google Docs ではスマホで md を気持ちよく読み書きできないから。Docs は Word 構造を引きずるので、素の Markdown 体験とは相性が悪い。「自分の Drive に置いた md を、スマホでそのまま育てたい」というのが出発点だった。

位置づけとしては、板書やメモを撮って md 化するアプリ（itadori）で種を作り、それを知識化して、bonsai で育てる、というパイプラインの「育てる」担当。技術スタックは React Native + Expo、認証は Google OAuth、保存基盤は Google Drive そのもの。サーバは持たず、端末から直接 Drive API を叩く構成だ。

実装自体はかなり進んだ。フォルダブラウザ、list / tree ビュー、md プレビュー、自動保存・競合検出つきのエディタ、日英の i18n、オンボーディング、課金土台まで。アプリとして動くところまでは、ちゃんと行った。

「動く」の遥か先にあった、公開までの関門#

AI と一緒だと実装は速い。でも、公開までにやることの本体はコードじゃなかった。並走してやったことを並べるとこれだけある。

Google Play ストア側

• Internal Testing への配信、データセーフティ申告、コンテンツレーティング、対象年齢設定
• 2023-11 以降に作った個人アカウントには「製品版アンロック」ルールがあり、Closed Testing をテスター 12 人 × 14 日間の opt-in 継続で完走しないと本番公開できない。テスターを集めるところ（Reddit の r/TestersCommunity 等）から始める必要がある

OAuth verification（Google Cloud）側 — ここが本題

• OAuth 同意画面の本番構成、承認済みドメインの所有権確認
• スコープごとに「なぜこの権限が要るのか」を説明する justification の英文
• プライバシーポリシーの整備。しかも homepage と PP を別 URL に分ける必要がある（同一だと差し戻される）
• デモ動画の作成。YouTube 限定公開・英語・同意画面にアプリ名が出る様子・スコープを実際に使う一連の操作（作成 / 編集 / 自動保存 / 削除して Drive のゴミ箱に入るまで）を収録。実機を adb で自動操作して録画し、字幕を焼き込む。これだけで一仕事だった
• 差し戻しとメール往復。「homepage と PP が同一」「審査側がログイン・テストできない」「アプリがダウンロードできない（Item not found）」…と、そのたびに原因を潰して英文で返信する。審査用の専用 Google アカウントを作り、内部アプリ共有のリンクを用意し、と延々続いた

学びとしてまず大きいのはここだ。「AI でアプリは作れる」と「アプリを出せる」は全然別で、リリースの手前にインフラ設定・ストア審査・OAuth 審査という非コードの長い道のりがある。むしろこっちが本番だった。

決定打：CASA の年額#

タイミングが、よりによってだった。OAuth の差し戻しを散々往復し、ストア側では製品版アンロックに必要な 12 人 × 14 日間のクローズドテストまで完走した後。公開まであと一歩、というところまで来ていた。そこへ 2026-07-16、Google の Third Party Data Safety Team から来たメールが決定打になった。

要約するとこうだ。restricted scope（今回は Google Drive の全アクセス drive）を使うアプリは、ADA-CASA AL1 というセキュリティ評価を毎年必須にする、と。

調べて分かったことを並べる¹。

• 昔あった無料のセルフスキャンは廃止済みで、認定ラボ（TAC Security など）経由が必須
• 費用は最安の TAC Security でも年額 ~$540。しかも 12 ヶ月ごとに更新
• 評価期間は 2〜6 週間

個人の趣味アプリ、しかも収益は控えめ、というものに毎年 $540 の経常コスト。ここで冷静になった。「これは割に合わない」。テスターを集めてクローズドテストの 14 日間を完走した直後だっただけに、正直これは結構な痛手だった。実装を AI で速く作れたぶん、この年額の重さがよけいに際立った。

省みて：無知だった点#

やってみて初めて分かった、最初に知っていれば設計が変わっていたことを並べる。

第一に、OAuth スコープには「非機密 / sensitive / restricted」の階層がある¹。restricted は審査が桁違いに重い（CASA・デモ動画・use case 説明・in-app testing…）。自分は何も知らずに、一番重い drive（全アクセス）を選んでいた。

第二に、drive.file という非機密スコープの選択肢があった。これなら CASA もデモ動画も不要になる。最初からこれで設計できていれば、審査地獄の大半は発生しなかった。

ただし drive.file には強い制約がある。アクセス権はフォルダの場所ではなく、ファイル単位の「素性」で決まる。つまりアプリが作ったファイルか、ユーザーが Picker で明示選択したファイルだけしか触れない¹。フォルダを選んでも中身は見えないし、外で作った既存 md を bonsai のフォルダに移動しても見えない。だから「Drive 全体を自由にブラウズして任意の md を開く」という bonsai の中核体験は、構造上 restricted scope でしか実現できなかった。ここが今回の詰みの本質だ。

第三に、「うちはサーバレスだから CASA 対象外だろう」という自己判断は通らない。実際、申請素材にはサーバを持たない構成図まで用意して「CASA のトリガー条件に該当しない見込み」で組んでいた。でも restricted scope なら一律必須で、トリガー条件がどうこうではなく、スコープの区分で決まる。

まとめると、権限スコープは設計の一番最初に、最小で選ぶべきだった。後から「実は restricted だと年額課金の審査が要る」と気づくと、作り込んだ体験ごと作り直しになる。

もう一つの選択肢：drive.file へ逃げる案#

撤退を決める前に、一度は drive.file へ移行して CASA を回避する案を検討し、実装にも着手した。

考えたのは「bonsai-home フォルダモデル」だ。My Drive 全体をブラウズするのをやめ、サインイン後にユーザーから見える bonsai という専用ルートフォルダを作り、その中だけを管理する。アプリが作ったフォルダ配下はすべてアプリ所有なので、drive.file でも list / tree・作成・移動・削除・編集・自動保存が全部動く。Drive 全体の走査は諦めるが、bonsai のサブツリー内なら今までどおり、という設計だ¹。

これで CASA・デモ動画・use case 説明・in-app testing の restricted 審査は丸ごと不要になる。技術的には成立する逃げ道だった。

残る制約は一つ。外部で作った既存 md は自動では見えない。ユーザーが Picker で 1 個ずつ明示選択したものだけが取り込める（アプリ専用の隠しフォルダ drive.appdata はユーザーから見えないので、Drive 寄生の思想と両立せず不採用にした）。「Drive 上の既存 md を、置いた場所そのままで開く」という当初の体験からは一歩後退する。

撤退、ただし作った資産は活かす#

逃げ道の設計まで用意したうえで、最後に自分の使い方を正直に見つめ直した。

• スマホで生成したメモを、その場で編集したい → ある
• スマホでクラウドを整理する / ファイルを見る → ほぼしない

つまり、育てる専用の閲覧・整理アプリの必要性が、自分にとっては薄かった。だったら編集機能は、撮る・録るアプリ（itadori / komadori）に「作った直後にその場で直す」機能として内蔵すればいい。それらは自分の生成物を書くだけなので drive.file で足り、CASA とは無縁だ。

そこで bonsai は寝かせる（dormant）ことにした。コードは消さない。作ったエディタ・プレビュー・自動保存の資産は、同じ React Native + Expo で動くキャプチャアプリ側へそのまま移植して活かす。撤退はゼロにすることではなく、作った部品をエコシステムの別の場所で再利用する形で畳む、という設計判断にした。

OAuth verification の申請自体は、Google のメールにある「キャンセルするなら返信を」に沿って取り下げ、同意画面は Testing へ戻し、restricted scope はコードからも消した。

まとめ — 最初に知っておきたかった3点#

同じところに向かう個人開発者に、遠回りした自分から3点だけ。

1. OAuth スコープには非機密 / sensitive / restricted の階層がある。この区分で審査の重さが桁違いに変わる
2. restricted scope を選ぶと、CASA という年額課金のセキュリティ評価（最安でも ~$540 / 年）が毎年ついてくる。「サーバレスだから対象外」は通らない
3. だから権限は設計の初手で最小に選ぶ。drive ではなく drive.file で成立するなら、迷わずそっち。後から気づくと、作り込んだ体験ごと作り直しになる

AI で作るのが速くなったぶん、詰まるのはコードの外側に移った。作れることと出せることのあいだにある溝を、この記事が少しでも先に見せられたなら幸いだ。

最後に。bonsai は畳んだけれど、アプリ開発そのものをやめる気はまったくない。今もクローズドテストに入っているアプリがひとつあるし、並行して仕込んでいるものもいくつかある。今回の学びをスコープ設計の初手に効かせながら、これらは普通に前へ進めていく。撤退の一つや二つでめげていたら、個人開発は続かない。次のリリースでまた会えたら嬉しい。

参考文献#

1. Google Workspace — Choose Google Drive API scopes（drive / drive.file の違いとスコープ区分） https://developers.google.com/workspace/drive/api/guides/api-specific-auth