課題
AIが作った調査報告書や分析結果を、そのまま次の作業の前提として使ってしまうことがある。今回、複数のアプリを個人開発している中で、別のAIに作らせたApp Storeのキーワード欄に関する調査報告書を元に改善を進めようとしたところ、その報告書の技術的な前提が実は間違っていた、という出来事があった。
解決できるようにすること
AIが作った成果物（自分自身の回答だけでなく、別のAIが作った報告書等も含む）を次の作業の前提にする前に、技術的な前提を検証できるようにする。
先に結論
報告書は「App Storeのキーワード欄は100バイト制限」という前提で改訂案を作っていた。WebSearchで確認したところ、公式ドキュメントの表記こそ「100バイト」だが、実際の運用は1文字＝1カウントの100文字制限で、日本語のような複数バイト言語が不利にならない仕組みだった。実際にバイト数を計測すると、5本のアプリ中4本が「バイト数換算では超過」に見えたが、文字数換算では全て45〜69文字で余裕があった。この前提のまま進めていたら、余裕のあるキーワードを不要に削ってしまうところだった。
この記事でわかること
- AIが作った調査報告書の技術的な前提を、どう検証すればよいか
- 「バイト数」と「文字数」という、見落としやすい制限の数え方の違い
報告書の内容を確認していたら
複数のアプリを運営している中で、そのうちの1本（色分けパズルゲーム「月灯り調合所」）について、別のAIに作らせたASO（App Store最適化）の調査報告書を持ち込み、その内容をもとに改善したいと考えた。あわせて、他の公開済みアプリ・今後リリース予定のアプリも対象を広げることにした。
報告書の中身を確認すると、営業目的の分析サービスからのメールをApple公式の警告と誤認せず正しく判定できている点や、単一のキーワードよりロングテールの複合キーワードを優先すべきという方針は、妥当な内容に見えた。
こう思う人もいるかもしれない。
「内容がしっかりしているなら、そのまま採用してよいのでは？」
ここで踏みとどまった。報告書は「キーワード欄は100バイト制限」という前提で、キーワードの改訂案を作っていた。この前提自体を検証せずに進めるのは危ういと感じた。
WebSearchで確認したら、前提が違っていた
WebSearchで確認したところ、Apple公式ドキュメントの表記は確かに「100バイト」だったが、実際のApp Store Connectの運用は1文字＝1カウントの100文字制限だと分かった。つまり、日本語のような複数バイトの文字を使う言語が、文字数の面で不利になるわけではない、ということになる。
「あれ、バイトと文字数で結果が変わってくるぞ」と気づいたのがこの時点だった。
実際に数えてみたら、削らなくてよかった
念のため、対象の5本のアプリについて、現行のキーワード欄をプログラムでバイト数・文字数の両方で計測してみた。結果は次のようになった。
- バイト数換算: 5本中4本が「100バイトを超過」しているように見える
- 文字数換算: 全て45〜69文字で、100文字の枠にまだ余裕があった
もし報告書の前提（100バイト制限）を疑わずに進めていたら、実際にはまだ余裕のあるキーワードを、不要に削ってしまうところだった。「危なかった、確認しておいてよかった」という感想が正直なところ。
実際に行った改善
前提を正しく確認した上で、5本のアプリ全てについて、キーワード欄からアプリ名・サブタイトルと重複する語を機械的に削除する整理を行った。いずれのアプリも文字数に余裕があったため、「容量不足で削る」という対応は発生せず、純粋な重複除去だけで済んでいる。内容面での取捨選択によるリスクは無かったことになる。
この訂正内容と、正しい運用ルール（文字数ベースであること、タイトル・サブタイトルとの重複回避の考え方）は、今後の新しいアプリにも使えるよう、正式なGuideline文書として残しておいた。一度気づいた前提の誤りを、その場限りで終わらせず、次に活かせる形にしておく狙いになる。
公開済みのアプリについては、確定した新しいキーワードをすぐに単体で反映するのではなく、次回の機能追加・不具合修正にあわせた審査提出のタイミングでまとめて反映する運用にした。メタデータの変更だけを理由に新しいバージョンを作る手間を避けるための判断になる。
気づいたこと
- AIが作った成果物は、自分自身への回答だけでなく、別のAIが作った報告書であっても、技術的な前提はそのまま信じず確認する価値がある
- 「バイト数」と「文字数」は、日本語のような複数バイト言語を扱う場合、結果が大きく変わることがある
- 前提を検証せずに進めていたら、余裕のあるものを不要に削るという、実害のある判断をしてしまうところだった
- 一度見つけた前提の誤りは、その場限りの修正で終わらせず、再利用できる文書として残しておくと、次に同じ確認をせずに済む
こんな人に向いている
複数のAIやAIが作った成果物を組み合わせて作業を進めている人には、「AIが作ったから」という理由だけで前提を信じ込まない姿勢が参考になる。特に文字数・容量のような技術的な制限は、実際に確認・計測してみる価値がある。
一方、「AIの成果物はいちいち疑わしい」と全てを警戒しすぎる必要はない。今回の報告書も、技術的な前提以外の判断（優先すべきキーワードの方針等）は妥当だった。どこを重点的に確認すべきかを見極める方が現実的になる。
まとめ
| 項目 | 内容 |
|---|---|
| 結論 | 別のAIが作った報告書の「100バイト制限」という前提は誤りで、実際は100文字制限だった。実測の結果、5アプリとも文字数に余裕があり、不要な削除を避けられた |
| 教訓 | AIが作った成果物の技術的な前提は、自分自身への回答か別のAIの成果物かにかかわらず検証する。見つけた誤りは再利用できる文書として残す |
| 対象読者 | 複数のAIを組み合わせて作業している人、App Store等のメタデータを扱っている人 |
同じ状況に陥ったときの回避策
- AIが作った報告書・分析結果を次の作業の前提にする前に、特に数値・制限に関わる技術的前提は公式情報で確認する
- 「バイト数」と「文字数」のように、見た目は似ていても結果が変わる数え方の違いに注意する
- 前提の誤りを見つけたら、その場の修正だけで終わらせず、今後も使える文書として残しておく
この記事は、筆者が実際に個人開発している複数のモバイルアプリの運営記録（2026年9月12日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。
