iOS | デジタルアーカイブシステムの技術ブログ

AI画像生成でiOSアプリアイコンを作るためのプロンプトテンプレート

はじめに iOSアプリのアイコンをAI画像生成ツール（Gemini、ChatGPT/DALL-E、Midjourney等）で作る際、Apple Human Interface Guidelines（HIG）に準拠した画像を一発で生成するのは意外と難しいです。よくある失敗: 角丸が事前に適用されている（iOSが自動で角丸マスクをかけるので不要）四隅に白い隙間があるテキストが入っている細かすぎて小サイズで潰れる本記事では、これらの問題を回避するプロンプトテンプレートを紹介します。テンプレート A flat, square 1024x1024 app icon for an iOS app called "{{APP_NAME}}" that {{APP_DESCRIPTION}}. Design requirements: - Fill the entire canvas edge-to-edge with a uniform {{BACKGROUND_COLOR}} background. No white areas, no transparency, no empty corners. - Do NOT include frames, borders, or decorative edges of any kind. - Center illustration: {{ILLUSTRATION_DESCRIPTION}}, rendered in {{INK_COLOR}} line art style. - Include one {{ACCENT_COLOR}} {{ACCENT_ELEMENT}} placed on the illustration to {{ACCENT_PURPOSE}}. - {{OPTIONAL_ELEMENT}} - Style: elegant, minimal color palette ({{COLOR_PALETTE}}), flat design, no gradients on illustration, no shadows, no 3D effects. - Detailed enough to be interesting but clear at small sizes (29px). Medium-weight lines. - Do NOT add any text, letters, or characters. - Do NOT pre-round corners — perfectly square image. iOS applies rounded corners automatically. - Output: square PNG, 1024x1024 pixels. ```text ## 変数一覧 | 変数 | 説明 | 例 | |------|------|-----| | `APP_NAME` | アプリ名 | IIIF AR | | `APP_DESCRIPTION` | 機能を1文で | places historical maps in AR | | `BACKGROUND_COLOR` | 背景色 | warm cream (#F0E4CC) | | `ILLUSTRATION_DESCRIPTION` | 中央イラストの内容 | a Japanese landscape with mountains | | `INK_COLOR` | イラストの線画色 | dark navy (#1A237E) | | `ACCENT_COLOR` | アクセント色 | blue (#1565C0) | | `ACCENT_ELEMENT` | アクセント要素 | AR pin marker | | `ACCENT_PURPOSE` | アクセントの意図 | suggest spatial placement | | `OPTIONAL_ELEMENT` | 追加要素（不要なら行ごと削除） | a subtle perspective grid | | `COLOR_PALETTE` | 色パレットの説明 | cream + navy + blue accent | ## 使用例 ### 歴史的絵図ARアプリ ```text A flat, square 1024x1024 app icon for an iOS app called "IIIF AR" that places high-resolution cultural heritage images in augmented reality at real-world scale. Design requirements: - Fill the entire canvas edge-to-edge with a uniform warm cream/parchment (#F0E4CC) background. No white areas, no transparency, no empty corners. - Do NOT include frames, borders, or decorative edges of any kind. - Center illustration: a stylized composition showing overlapping cultural heritage imagery — such as a fragment of a traditional Japanese landscape painting with mountains, water, and architecture — rendered in dark navy (#1A237E) line art style. - Include one blue (#1565C0) location/AR pin marker placed on the illustration to suggest spatial placement. - Optionally include a subtle perspective grid (2-3 thin lines) at the bottom to hint at AR floor placement. - Style: elegant, minimal color palette (cream + navy ink + one blue accent), flat design, no gradients on illustration, no shadows, no 3D effects. - Detailed enough to be interesting but clear at small sizes (29px). Medium-weight lines. - Do NOT add any text, letters, or characters. - Do NOT pre-round corners — perfectly square image. iOS applies rounded corners automatically. - Output: square PNG, 1024x1024 pixels. ```text ### くずし字OCRアプリ ```text A flat, square 1024x1024 app icon for an iOS app called "KotenOCR" that recognizes classical Japanese cursive script (kuzushiji) using on-device AI. Design requirements: - Fill the entire canvas edge-to-edge with a uniform warm ivory (#FAF3E8) background. No white areas, no transparency, no empty corners. - Do NOT include frames, borders, or decorative edges of any kind. - Center illustration: a stylized fragment of a classical Japanese manuscript page with elegant brushstroke characters, rendered in dark sumi ink (#2C1810) line art style. - Include one teal (#00897B) scanning/recognition indicator (such as a viewfinder bracket or highlight box) placed over one character to suggest OCR recognition. - Style: elegant, minimal color palette (ivory + sumi ink + one teal accent), flat design, no gradients on illustration, no shadows, no 3D effects. - Detailed enough to be interesting but clear at small sizes (29px). Medium-weight lines. - Do NOT add any text, letters, or characters. - Do NOT pre-round corners — perfectly square image. iOS applies rounded corners automatically. - Output: square PNG, 1024x1024 pixels. ```text ## Apple HIG準拠チェックリスト生成後に以下を確認してください。 - [ ] 正方形（1024×1024px）で、角丸なし - [ ] 四隅まで背景色で塗りつぶされている（透明や白の隙間なし） - [ ] テキストが含まれていない - [ ] 写真ではなくイラスト/グラフィック - [ ] 29pxに縮小しても何のアプリかわかる - [ ] Apple製品のレプリカが含まれていない - [ ] カスタムのハイライトやドロップシャドウがない ## 適用方法 ```bash # 生成した画像を配置 cp ~/Downloads/generated_icon.png \ {PROJECT}/Assets.xcassets/AppIcon.appiconset/AppIcon.png # ビルドして確認 xcodegen generate xcodebuild build -project {PROJECT}.xcodeproj -scheme {SCHEME} ... ```text ## 参考 - [Apple Human Interface Guidelines - App Icons](https://developer.apple.com/design/human-interface-guidelines/app-icons)

2026年3月24日 · 4 分 · Nakamura

App Store審査リジェクト後の修正・再提出をApp Store Connect APIで実行する

App Store Connect の審査でリジェクトされた後、修正からの再提出までの全工程を API で実行しました。ブラウザでの操作は一切行っていません。リジェクトの内容 JPS Explorer（ジャパンサーチ文化資源探索アプリ）の初回提出で、2つの問題を指摘されました。チップ（Tip Jar）画面でエラーが表示される — In-App Purchase の商品が App Store Connect に未登録だったためカメラ検索の「撮影」ボタンでクラッシュ — iOS の Info.plist に NSCameraUsageDescription が未設定だったため修正内容カメラクラッシュの修正 Info.plist にカメラと写真ライブラリの権限記述を追加しました。 <key>NSCameraUsageDescription</key> <string>文化資源に似た画像を検索するためにカメラを使用します</string> <key>NSPhotoLibraryUsageDescription</key> <string>文化資源に似た画像を検索するために写真ライブラリを使用します</string> Flutter の image_picker パッケージを使ってカメラにアクセスする場合、この記述がないと実機でクラッシュします。シミュレータではカメラが使えないため、この問題には気づきにくいようです。合わせて、PlatformException の camera_access_denied と photo_access_denied のハンドリングも追加しました。チップ画面の修正 In-App Purchase の商品が未登録の場合、StoreKit がエラーを返します。エラーをそのまま表示するのではなく、「準備中です」というメッセージに変更しました。 API による再提出の手順リジェクト後の状態では、App Store Connect のブラウザに「編集」ボタンと「App Reviewに再提出」ボタンが表示されます。これらの操作はすべて API で実行できます。 Step 1: ビルド番号を上げてアップロードリジェクトされたビルドと同じビルド番号では再アップロードできないため、pubspec.yaml のビルド番号を上げます。 # 変更前 version: 1.0.0+1 # 変更後 version: 1.0.0+2 ビルドしてアップロードします。 ...

2026年3月24日 · 2 分 · Nakamura

Firebase不要：Apple標準ツールだけでiOSアプリを運用する

はじめに iOSアプリの運用を始めると、すぐに以下のような課題に直面します。クラッシュしているのか、どこで落ちているのか知りたいダウンロード数やセッション数を把握したい古いバージョンのユーザーにアップデートを促したいレビューを書いてもらいたい多くの記事が Firebase Crashlytics + Firebase Analytics の導入を勧めますが、これはGoogleのサーバーにユーザーのデバイス情報・使用状況・クラッシュログなどを送信することを意味します。App Storeへの提出時にも「データ収集・追跡」の申告が必要になります。個人開発や学術目的のアプリでは、そこまでのデータ収集が本当に必要でしょうか？本記事では、ユーザーデータを外部に送信せず、Apple標準ツールとOSSだけで運用する構成を、実際のApp Store公開アプリ KotenOCR での経験をもとに紹介します。構成の全体像目的 Firebase構成本記事の構成外部送信クラッシュ計測 Crashlytics MetricKit なしアナリティクス Firebase Analytics App Store Connect Analytics API なしアップデート促進 Remote Config Siren（iTunes Lookup API）なし※ レビュー促進 In-App Messaging SKStoreReviewRequest なしクラッシュログ閲覧 Crashlytics Console Xcode Organizer なし ※ Sirenは iTunes Lookup API（Apple公式）にバージョン確認のリクエストを送りますが、ユーザーの個人情報は含まれません。 1. MetricKit — クラッシュ計測 MetricKit はiOS 13+で利用可能なApple標準フレームワークです。クラッシュレポート、ハング（応答なし）、起動時間などのパフォーマンスデータをアプリ内で受け取れます。実装 import MetricKit class MetricKitManager: NSObject, MXMetricManagerSubscriber { static let shared = MetricKitManager() func start() { MXMetricManager.shared.add(self) } // iOS 15+: クラッシュ・ハングの即時通知 func didReceive(_ payloads: [MXDiagnosticPayload]) { for payload in payloads { if let crashDiagnostics = payload.crashDiagnostics { for crash in crashDiagnostics { // クラッシュのスタックトレースを処理 let description = crash.callStackTree.jsonRepresentation() // ログに記録、またはローカルに保存 } } } } // iOS 14+: 24時間ごとのパフォーマンスメトリクス func didReceive(_ payloads: [MXMetricPayload]) { for payload in payloads { // 起動時間、メモリ使用量、ディスクI/Oなど } } } ```text アプリの起動時に `MetricKitManager.shared.start()` を呼ぶだけです。 ### MetricKitの特徴 - **外部送信なし** — データはアプリ内で完結。Appleのサーバーにも送らない - **即時通知** — iOS 15以降、クラッシュ直後に `didReceive(_: [MXDiagnosticPayload])` が呼ばれる - **バッテリー・パフォーマンス** — クラッシュだけでなく、起動時間やメモリ使用量も計測できる ### Xcode Organizer との違い Xcode Organizer（Xcode → Window → Organizer → Crashes）も追加実装なしでクラッシュログを表示しますが、以下の制限があります。 - ユーザーが「診断データ共有」をオンにしている必要がある（オプトイン） - ある程度のユーザー数がないとデータが集まらない - 蓄積に数日〜数週間かかるユーザー数が少ない段階では MetricKit の方が実用的です。 ## 2. App Store Connect Analytics API — アナリティクス App Store Connect のWebコンソールでもアナリティクスは見られますが、APIで取得すると自動化や詳細な分析が可能になります。 ### 準備：JWT認証 App Store Connect APIは JWT（JSON Web Token）で認証します。 ```python import jwt import time import requests KEY_ID = "YOUR_KEY_ID" ISSUER_ID = "YOUR_ISSUER_ID" with open("AuthKey.p8", "r") as f: private_key = f.read() payload = { "iss": ISSUER_ID, "iat": int(time.time()), "exp": int(time.time()) + 1200, "aud": "appstoreconnect-v1" } token = jwt.encode(payload, private_key, algorithm="ES256", headers={"kid": KEY_ID}) headers = {"Authorization": f"Bearer {token}"} ```text ### レポートリクエストの作成 Analytics APIを使うには、まずレポートリクエストを作成（または既存のものを取得）します。 ```python APP_ID = "YOUR_APP_ID" # レポートリクエストの確認 r = requests.get( f"https://api.appstoreconnect.apple.com/v1/apps/{APP_ID}/analyticsReportRequests", headers=headers ) report_requests = r.json()["data"] # なければ作成（ONGOINGで継続的にレポート生成） if not report_requests: r = requests.post( f"https://api.appstoreconnect.apple.com/v1/apps/{APP_ID}/analyticsReportRequests", headers=headers, json={ "data": { "type": "analyticsReportRequests", "attributes": {"accessType": "ONGOING"}, "relationships": { "app": {"data": {"type": "apps", "id": APP_ID}} } } } ) ```text ### レポートの取得 ```python import gzip import csv import io from collections import defaultdict REPORT_REQUEST_ID = report_requests[0]["id"] def fetch_report(report_name): """指定したレポートの全インスタンスを取得して結合""" # レポート一覧を取得 r = requests.get( f"https://api.appstoreconnect.apple.com/v1/analyticsReportRequests/" f"{REPORT_REQUEST_ID}/reports", headers=headers, params={"limit": 200} ) for report in r.json()["data"]: if report["attributes"]["name"] == report_name: # インスタンス（日付ごとのデータ）を取得 r2 = requests.get( f"https://api.appstoreconnect.apple.com/v1/analyticsReports/" f"{report['id']}/instances", headers=headers, params={"limit": 10} ) all_data = "" for inst in r2.json().get("data", []): # セグメント（実際のデータファイル）を取得 r3 = requests.get( f"https://api.appstoreconnect.apple.com/v1/" f"analyticsReportInstances/{inst['id']}/segments", headers=headers ) for seg in r3.json().get("data", []): url = seg["attributes"].get("url") if url: r4 = requests.get(url) text = gzip.decompress(r4.content).decode("utf-8") lines = text.strip().split("\n") if not all_data: all_data = text.strip() else: all_data += "\n" + "\n".join(lines[1:]) return all_data return None ```text ### 利用可能なレポートの例 | レポート名 | カテゴリ | 内容 | |-----------|---------|------| | App Downloads Standard | COMMERCE | ダウンロード数（新規/再DL、デバイス、地域別） | | App Sessions Standard | APP_USAGE | セッション数、平均時間 | | App Store Discovery and Engagement Standard | APP_STORE_ENGAGEMENT | インプレッション、ページ閲覧、タップ | | App Store Installation and Deletion Standard | APP_USAGE | インストール・削除数 | | App Crashes | APP_USAGE | クラッシュ数 | ### 実際の出力例 KotenOCRの公開直後のデータです。 ```text === ダウンロード数 === 2026-03-20: 新規 95 / 再DL 2 / 計 97 2026-03-21: 新規 348 / 再DL 14 / 計 362 2026-03-22: 新規 104 / 再DL 188 / 計 292 2026-03-23: 新規 23 / 再DL 231 / 計 254 合計: 新規 570 / 再DL 435 / 計 1,005 === セッション数 === 2026-03-20: 159 セッション / 平均 81秒 2026-03-21: 345 セッション / 平均 85秒 2026-03-22: 126 セッション / 平均 84秒 2026-03-23: 50 セッション / 平均 115秒 === App Store エンゲージメント === 2026-03-19: Impression: 79 / Page view: 14 / Tap: 19 2026-03-20: Impression: 172 / Page view: 315 / Tap: 336 2026-03-21: Impression: 596 / Page view: 576 / Tap: 600 2026-03-22: Impression: 193 / Page view: 106 / Tap: 101 === インストール / 削除 === 2026-03-20: インストール 63 / 削除 0 2026-03-21: インストール 249 / 削除 0 2026-03-22: インストール 66 / 削除 0 2026-03-23: インストール 56 / 削除 0 ```text データの遅延は約1〜2日です。Web UIではほぼ前日分まで閲覧できます。 ## 3. Siren — アップデート促進 [Siren](https://github.com/ArtSabintsev/Siren) は、App Storeの最新バージョンとアプリのバージョンを比較し、更新を促すダイアログを表示するOSSライブラリです。 ### 導入 Swift Package Manager で追加します。 ```text https://github.com/ArtSabintsev/Siren (6.1.0+) ```text ### 実装 ```swift import Siren // SwiftUIの場合、onAppear内で呼ぶこと（init()では動かない） private func configureSiren() { let siren = Siren.shared siren.rulesManager = RulesManager( majorUpdateRules: .critical, // メジャー: スキップ不可 minorUpdateRules: .annoying, // マイナー: スキップ不可（後で通知） patchUpdateRules: .default // パッチ: スキップ可能 ) siren.wail() } ```text ### 注意点 - **SwiftUIでは `onAppear` で呼ぶ** — `App.init()` の段階ではUIWindowが存在しないため、Sirenが正しく動作しません - **テスト方法** — Sirenは iTunes Lookup API で App Store上のバージョンと比較するため、テスト時は Info.plist の `CFBundleShortVersionString` を意図的に古いバージョンに設定する必要があります - **リリース直後の遅延** — デフォルトでリリースから1日経過しないとダイアログが表示されません（`showAlertAfterCurrentVersionHasBeenReleasedForDays` で変更可能） ### ダイアログの種類 | ルール | 動作 | |--------|------| | `.critical` | 「Update」ボタンのみ。スキップ不可 | | `.annoying` | 「Update」「Next time」の2ボタン。スキップ不可だが後回し可 | | `.default` | 「Update」「Next time」「Skip」の3ボタン | | `.relaxed` | `.default` と同じだが、表示頻度が低い | ## 4. SKStoreReviewRequest — レビュー促進 Apple標準のレビュー促進APIです。追加のフレームワークは不要です。 ```swift import StoreKit // OCR成功後など、ユーザーが価値を感じたタイミングで呼ぶ func requestReviewIfAppropriate() { let count = UserDefaults.standard.integer(forKey: "ocrSuccessCount") // 3回目のOCR成功後にレビューを依頼 if count == 3 { if let scene = UIApplication.shared.connectedScenes .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene { SKStoreReviewController.requestReview(in: scene) } } } ```text ### ポイント - Appleがダイアログの表示を制御するため、呼び出しても必ず表示されるとは限らない - **年3回まで**の制限がある - ユーザーが「成功体験」を感じた直後に呼ぶのが効果的 ## 5. 所感と限界 ### この構成でカバーできること - 基本的なダウンロード数・セッション数の把握 - クラッシュの検知と原因調査 - ユーザーへのアップデート促進 - レビュー促進実際に KotenOCR をこの構成で運用していますが、個人開発アプリとしては十分な情報が得られています。 ### この構成の限界 - **画面単位・機能単位の詳細な計測ができない** — 「どの画面が最も使われているか」「翻訳機能の利用率は？」といった分析にはアプリ内のイベント計測が必要 - **リアルタイム性がない** — Analytics APIのデータには1〜2日の遅延がある - **MetricKitのクラッシュ情報は構造化されていない** — スタックトレースのJSON解析は自前で実装する必要がある - **A/Bテストや段階的ロールアウトは不可能** — これらが必要な場合はFirebase Remote Configなどが必要 ### Firebaseが必要になるケース - ユーザー行動の詳細な分析が必要な場合 - リアルタイムのクラッシュ通知が必要な場合 - Feature Flagsやリモート設定が必要な場合 - プッシュ通知を実装する場合 ## まとめ | ツール | 用途 | 実装コスト | |--------|------|-----------| | MetricKit | クラッシュ・パフォーマンス計測 | 小 | | App Store Connect Analytics API | DL数・セッション・エンゲージメント | 中（Python） | | Siren | アップデート促進ダイアログ | 小 | | SKStoreReviewRequest | レビュー促進 | 最小 | | Xcode Organizer | クラッシュログ閲覧 | なし | Firebase不要でも、個人開発アプリの運用に必要な情報はほぼ揃います。プライバシーポリシーの記載義務も最小限で済み、ユーザーに対して「データを収集していません」と言い切れるのは大きなメリットです。まずはこの構成で始めて、必要に応じてFirebaseを追加する、という段階的なアプローチがおすすめです。 ## 関連記事 - [KotenOCR：くずし字をオフラインで認識するiOSアプリの開発と公開](/posts/kotenocr-ios-app/) - [App Store Connect APIだけでiOSアプリを審査提出する手順](/posts/appstore-connect-api-guide/) - [iOSアプリのメモリ最適化とクラッシュ修正の実践記録](/posts/ios-memory-crash-fixes/)

2026年3月24日 · 5 分 · Nakamura

ジャパンサーチAPIを活用した文化資源探索アプリの開発とApp Store公開

ジャパンサーチ（ https://jpsearch.go.jp ）のWeb APIを使い、日本の文化資源を探索するiOS/Androidアプリ「JPS Explorer」を開発しました。API調査からアプリ実装、App Storeリリースの自動化までの過程を記録します。ジャパンサーチのAPI ジャパンサーチは国立国会図書館が運営する、3,200万件以上のデジタル文化資源のメタデータを横断検索できるサービスです。簡易Web APIが公開されており、以下のような検索が可能です。パラメータ機能 keyword キーワード検索 text2image テキストでモチーフを指定して画像検索 image 既存アイテムIDで類似画像検索 g-coordinates 緯度・経度・半径で場所検索 r-tempo 年代範囲で時代検索 API調査で気づいた点座標フィールドのキー名位置情報検索（g-coordinates）のレスポンスで座標データは common.coordinates に格納されています。経度のキーは lon で、lng や longitude ではありません。 "coordinates": { "lat": 35.669, "lon": 139.764 } ギャラリーAPIの多言語フィールドギャラリー検索（/api/curation/search）のレスポンスでは、title と summary が文字列ではなくオブジェクトになっています。 "title": {"ja": "耳鳥斎", "en": "Jichosai"}, "image": {"url": "https://...", "thumbnailUrl": "https://..."} 単純に .toString() すると {ja: 耳鳥斎, en: Jichosai} のような文字列がUIに表示されてしまうため、言語キーでアクセスする必要があります。ギャラリー詳細のアイテム構造ギャラリー詳細（/api/curation/{id}）のアイテムは contents ではなく parts 配列にネストされています。type: "jps-curation-list-item" を再帰的に探索してIDを収集する必要がありました。一部のギャラリーでは subPages にもアイテムが含まれているようです。画像アップロードによる類似検索公式APIガイドには記載されていませんが、Web UIのネットワーク通信を調査したところ、画像アップロードによる類似検索が3段階のAPIで実現されていることがわかりました。 POST /dl/api/imagefeatures/ で画像のBase64データから64次元の特徴量ベクトルを取得 POST /api/item/create-image-feature で特徴量から一時的な検索IDを生成 GET /api/item/search/jps-cross?image={ID} で通常の類似検索を実行 Step 2では X-Requested-With: XmlHttpRequest ヘッダーが必要で、レスポンスはプレーンテキストでIDが返ります。 ...

2026年3月24日 · 3 分 · Nakamura

iOS OCRアプリのメモリ起因クラッシュの調査と対策

KotenOCRは古典籍のOCR処理にONNX Runtimeを使用しているiOSアプリです。6つのONNXモデル（合計約230MB）を搭載しています。ダウンロード数が300に達した時点で、クラッシュ率が6.7%（20件）に上昇していることが確認されました。Xcode Organizerにクラッシュログが表示されなかったため、原因の特定には別のアプローチが必要でした。調査体制 4つの調査方針を並行して進めました。メモリ・モデルサイズの調査画像処理パイプラインの調査 ONNX Runtimeのスレッドセーフティの調査カメラ・UIライフサイクルの調査原因の特定調査の結果、以下の4つの問題が確認されました。影響度の大きい順に記載します。 1. 起動時の全モデル一括ロード 6つのONNXモデルをアプリ起動時にすべてメモリに展開していました。ディスク上では約230MBですが、ONNX Runtimeがモデルをメモリに展開すると1.5〜2.5倍程度に膨張するため、RAM上では推定350〜550MB程度を占有していたと考えられます。 iOSにはjetsam（カーネルレベルのメモリ監視機構）があり、アプリ単位のメモリ上限を超えるとプロセスが強制終了されます。デバイスごとのRAMとアプリあたりのメモリ上限の目安は以下のとおりです。デバイス RAM リスク iPhone 8 2GB CRITICAL — iOS 16対応機種で最もメモリが少ない iPhone X / XR / XS 3GB HIGH iPhone 11 4GB MEDIUM iPhone 12以降 4〜6GB LOW iPhone 8やiPhone Xでは、アプリあたりのメモリ上限が200〜300MB程度とされており、全モデル一括ロードだけで上限を超過する状況でした。 2. DEIMDetectorの画像前処理 DEIMDetectorが入力画像をリサイズせずにフルサイズのまま正方形パディング用のCGContextを生成していました。12MPの写真（4032×3024）の場合、4032×4032ピクセルのCGContextが作成され、これだけで約63MBのメモリを消費します。 3. 無制限の並列認識タスク withThrowingTaskGroupで最大100件の認識タスクを同時に実行可能な状態でした。各タスクがモデル推論時にメモリを確保するため、並列数に比例してメモリ使用量が増加します。 4. メモリ警告のハンドリング不在 UIApplication.didReceiveMemoryWarningNotificationを購読しておらず、iOSからのメモリ警告を受け取っても何も対処していませんでした。jetsam発動前の最後の解放機会を逃していたことになります。実施した修正 Lazy Model Loading 起動時にすべてのモデルをロードする方式から、選択中のモードに必要なモデルのみをロードする方式に変更しました。初期メモリ使用量が約350MBから約150MBに減少しました。 func loadModelsForMode(_ mode: OCRMode) { // 選択中のモードに必要なモデルのみロード let requiredModels = mode.requiredModelKeys for key in requiredModels { if sessionCache[key] == nil { sessionCache[key] = try? createSession(for: key) } } } 画像前処理の改善 DEIMDetectorの前処理で、パディング前にリサイズを行うように変更しました。メモリ使用量が63MBから約2.4MBに削減されました。 ...

2026年3月23日 · 2 分 · Nakamura

KotenOCR: 近代OCRの検出重複を解消する（NMS追加とクラスフィルタリング）

はじめに KotenOCRは、国立国会図書館（NDL）が公開したOCRモデルをiOS上で動作させ、くずし字や近代活字をオフラインで認識するアプリです。近代OCRモード（NDLモード）では、NDLのDEIMv2-Sモデルでレイアウト検出を行い、PARSeQで文字認識を行います。しかし、iOS実装の検出結果が本家のndlocr-liteと比べて明らかに多く、テキストが重複して認識されるという問題がありました。本記事では、原因の調査から修正までの過程を記録します。症状：検出数が多すぎるテスト画像として、NDLデジタルコレクションから取得した「校異源氏物語」の序文ページを使いました。本家ndlocr-liteでは17件の行検出（line_main、line_captionなど）が得られるのに対し、iOS実装では28件の検出が返り、OCR結果にも重複テキストや文字化けが混入していました。検出数が多い原因は大きく3つありました。原因1：NMS（Non-Maximum Suppression）が未実装だった DEIMv2モデルのONNX出力は、内部でNMSを完了した結果を返すと想定していました。しかし本家ndlocr-liteのコードを読むと、モデル推論後に追加のNMS（IoU閾値=0.2）を適用していることがわかりました。つまり、モデル出力にはまだ重複する矩形が含まれており、後処理でそれを除去する必要があったのです。修正：NMSの追加 DEIMDetector.swiftにNMS処理を追加しました。 // DEIMDetector.swift — postprocess() の末尾 // Sort by score descending let sorted = detections.sorted { $0.score > $1.score } // Apply NMS to remove overlapping detections let nmsResult = applyNMS(sorted, iouThreshold: iouThreshold) return Array(nmsResult.prefix(maxDetections)) NMS本体の実装は以下のとおりです。スコア降順にソートされた検出結果を走査し、既に採用した矩形とのIoUが閾値を超える場合は除外します。 // DEIMDetector.swift /// Apply Non-Maximum Suppression to remove overlapping detections. private func applyNMS(_ detections: [Detection], iouThreshold: Float) -> [Detection] { var kept: [Detection] = [] for det in detections { var shouldKeep = true for existing in kept { if computeIoU(det.box, existing.box) > iouThreshold { shouldKeep = false break } } if shouldKeep { kept.append(det) } } return kept } /// Compute Intersection over Union between two boxes [x1, y1, x2, y2]. private func computeIoU(_ a: [Int], _ b: [Int]) -> Float { let x1 = max(a[0], b[0]) let y1 = max(a[1], b[1]) let x2 = min(a[2], b[2]) let y2 = min(a[3], b[3]) let interW = max(0, x2 - x1) let interH = max(0, y2 - y1) let interArea = Float(interW * interH) let areaA = Float((a[2] - a[0]) * (a[3] - a[1])) let areaB = Float((b[2] - b[0]) * (b[3] - b[1])) let unionArea = areaA + areaB - interArea guard unionArea > 0 else { return 0 } return interArea / unionArea } 原因2：全クラスをOCRに送っていた DEIMv2モデルは17クラスのレイアウト要素を検出します。 ...

2026年3月23日 · 2 分 · Nakamura

Swift ConcurrencyでOCR認識処理を並列化し最大6.7倍高速化する

OCRパイプラインの構造 iOSでONNX Runtimeを使ったOCRパイプラインは、大まかに以下の流れで動作します。画像全体に対する文字領域検出（Detection）検出された各領域に対する文字認識（Recognition）読み順の推定と結合この中で、検出は画像全体に対して1回だけ実行されます。一方、認識は検出された領域の数だけ繰り返されます。領域数が多い画像では、認識処理が全体の処理時間の大部分を占めることになります。逐次処理の問題認識処理を単純なforループで逐次実行すると、処理時間は領域数にほぼ比例します。 for det in detections { let rect = CGRect(x: max(0, det.box[0]), y: max(0, det.box[1]), width: max(1, det.box[2] - det.box[0]), height: max(1, det.box[3] - det.box[1])) if let cropped = image.cropping(to: rect) { _ = try recognizer.recognize(image: cropped) } } たとえば98領域が検出された画像の場合、1領域あたり約80msとすると合計で約8秒かかります。 withThrowingTaskGroupによる並列化 Swift ConcurrencyのwithThrowingTaskGroupを使うと、各領域の認識処理を並列に実行できます。 let results = try await withThrowingTaskGroup(of: (Int, String).self) { group in for i in 0..<detections.count { let box = detections[i].box let cropRect = CGRect( x: max(0, box[0]), y: max(0, box[1]), width: max(1, box[2] - box[0]), height: max(1, box[3] - box[1]) ) guard let cropped = image.cropping(to: cropRect) else { continue } group.addTask { let text = try recognizer.recognize(image: cropped) return (i, text) } } var texts: [(Int, String)] = [] for try await result in group { texts.append(result) } return texts } for (i, text) in results { recognized[i].text = text } 各タスクはインデックスとともに結果を返すため、完了順序に関係なく元の順序を保持できます。ベンチマーク結果 iOSシミュレータ上で、逐次処理と並列処理の実行時間を比較しました。古典籍（源氏物語、6642x4990px、21領域）出典: 東京大学デジタルアーカイブ源氏物語方式処理時間逐次 4.55s 並列 3.24s 高速化率 1.4x 近代活字（NDLデジタルコレクション、6890x4706px、98領域）出典: 国立国会図書館デジタルコレクション方式処理時間逐次 7.59s 並列 1.13s 高速化率 6.7x 高速化率が異なる理由 21領域の場合と98領域の場合で高速化率に差が出ています。 ...

2026年3月21日 · 1 分 · Nakamura

KotenOCR：くずし字をオフラインで認識するiOSアプリの開発と公開

はじめに古典籍に書かれたくずし字（変体仮名・草書体の漢字）を読むのは、専門家でも容易ではありません。近年はAI-OCRによって機械的な認識が可能になってきましたが、調査した限り、スマートフォンでオフライン利用できるツールは見当たりませんでした。 KotenOCRは、国立国会図書館（NDL）が公開した軽量くずし字OCRモデル「NDL古典籍OCR-Lite」をiOS上で動作させ、写真を撮るだけでくずし字を認識できるアプリです。 App Store（無料）: https://apps.apple.com/jp/app/kotenocr/id6760045646 背景：既存ツールの状況 NDLが「NDL古典籍OCR-Lite」を公開したことで、くずし字OCRの敷居は下がりました。既存ツールを見渡すと以下のような状況でした。ツール形態インターネット接続 NDL古典籍OCR-Lite デスクトップ / Web / CLI 不要（デスクトップ版） miwo（CODH）モバイルアプリ必要古文書カメラ（TOPPAN）モバイルアプリ必要モバイルアプリは存在するものの、いずれもクラウド通信が必要です。一方、NDL古典籍OCR-LiteはPC環境でしか動作しません。そこで、NDL古典籍OCR-Liteのモデルをスマートフォンに載せて、オフラインで動くiOSアプリを作ることにしました。 KotenOCRの特徴完全オフライン — すべての処理がデバイス上で完結。通信不要 iPhone / iPad対応 — iOS 16.0以上無料 — App Storeから無料でダウンロード可能スキャン履歴 — 認識結果を保存・管理 TXT / PDFエクスポート — 認識テキストをファイルとして出力範囲トリミング — 認識する領域を指定可能使い方古典籍の写真を撮影する（またはライブラリから選択） AIがくずし字を自動認識認識されたテキストをコピー・エクスポート OCRパイプライン写真からテキストが認識されるまでの処理フローは以下の通りです。写真 → トリミング → テキスト領域検出 → 文字認識 → 読み順決定 → 表示テキスト領域検出: RTMDetモデルにより、画像内の文字領域を検出文字認識: PARSeqモデルにより、検出領域内の文字を認識（7,141文字、NDLmojiの文字集合に対応）読み順: 日本語の縦書き・右から左への読み順を考慮して並べ替え ...

2026年3月20日 · 1 分 · Nakamura

App Storeのスクリーンショット生成をPython+UIテストで完全自動化する

TL;DR XCUITestでiPhone・iPadシミュレータのスクリーンショットを日英両言語で自動撮影 PythonのPillowでグラデーション背景＋デバイスフレーム＋テキストオーバーレイのマーケティング画像を生成 xcrun simctl io recordVideoでデモ動画も録画 App Store Connect APIで自動アップロードすべてをシェルスクリプト1本で実行可能はじめに iOSアプリのApp Storeスクリーンショットは、iPhone 6.7インチ、iPad 12.9インチの各サイズを日英2言語分用意すると、それだけで12枚以上の画像を作る必要があります。アプリを更新するたびに手作業でスクリーンショットを撮り直し、FigmaやPhotoshopでマーケティング画像を作り、App Store Connectに1枚ずつアップロードするのは手間がかかります。本記事では、撮影 → 画像生成 → アップロードの全工程をコマンド一発で実行できるパイプラインの構築方法を解説します。全体構成 capture_screenshots.sh ├── Step 1: シミュレータの準備（起動 + テスト画像追加） ├── Step 2: XCUITestでスクリーンショット撮影（JA/EN × iPhone/iPad） ├── Step 3: sipsでApple規定サイズにリサイズ ├── Step 4: Pillow でマーケティング画像を生成 ├── Step 5: xcrun simctl io でデモ動画を録画 └── Step 6: App Store Connect APIでアップロード Step 1: XCUITestでスクリーンショットを撮影するテストコードの設計 UIテスト用のテストクラスを作成します。ポイントは以下の3つです。テスト画像の自動読み込み: TEST_IMAGE_PATH環境変数で画像パスを渡し、PHPickerを経由せずに画像を直接ロードします言語切り替え: xcodebuild -testLanguageで設定された言語を-AppleLanguagesとしてアプリに渡しますレビューダイアログの抑制: 起動引数で不要なダイアログを抑制します final class ScreenshotTests: XCTestCase { private var app: XCUIApplication! private let screenshotDir = ProcessInfo.processInfo.environment["SCREENSHOT_DIR"] ?? "/tmp/myapp_screenshots" override func setUpWithError() throws { continueAfterFailure = false app = XCUIApplication() // オンボーディングをスキップ、レビューダイアログを抑制 app.launchArguments += ["-hasCompletedOnboarding", "YES"] // テスト言語をアプリの言語設定に反映 let preferredLang = Locale.preferredLanguages.first ?? "ja" let langCode = preferredLang.components(separatedBy: "-").first ?? "ja" app.launchArguments += ["-AppleLanguages", "(\(langCode))", "-AppleLocale", langCode] // テスト用画像パスを環境変数で渡す app.launchEnvironment["TEST_IMAGE_PATH"] = "/path/to/test_sample.jpg" try FileManager.default.createDirectory( atPath: screenshotDir, withIntermediateDirectories: true ) } func testCaptureScreenshots() throws { app.launch() // 処理完了を待機 let backButton = app.buttons["back_button"] XCTAssertTrue(backButton.waitForExistence(timeout: 300)) sleep(2) // メイン画面のスクリーンショット saveScreenshot(name: "04_result") // 他の画面に遷移してスクリーンショットを撮る // ... backButton.tap() sleep(1) saveScreenshot(name: "01_camera") } private func saveScreenshot(name: String) { let screenshot = app.windows.firstMatch.screenshot() let attachment = XCTAttachment(screenshot: screenshot) attachment.name = name attachment.lifetime = .keepAlways add(attachment) let path = "\(screenshotDir)/\(name).png" try? screenshot.pngRepresentation.write(to: URL(fileURLWithPath: path)) } } saveScreenshotメソッドは、XCTestのXCTAttachmentとしてテスト結果に添付すると同時に、指定ディレクトリにPNGファイルとして保存します。ファイル名のプレフィックス（01_, 04_等）は、後のマーケティング画像生成で優先順位を制御するために使います。 ...

2026年3月19日 · 8 分 · Nakamura

App Store Connect APIでiOSアプリのアップデートを審査提出する方法

TL;DR iOSアプリのアップデート版をビルド → アップロード → ビルド紐付け → whatsNew設定 → 審査提出まで、すべてコマンドラインとApp Store Connect REST APIで完結させた。初回リリース時と異なり、メタデータやスクリーンショットは既存のものが引き継がれるため、更新時に必要な操作は少ない。前提: App Store Connect APIだけでiOSアプリを審査提出する完全ガイドのセットアップ（APIキー取得・JWT生成・ヘルパー関数）が完了しているものとする。全体の流れビルド番号のインクリメントアーカイブ・IPA書き出し・アップロード（xcodebuild + xcrun altool）ビルドの処理完了を確認（API）ビルドをバージョンに紐付け（API）暗号化コンプライアンスの設定（API） whatsNew（新機能）の設定（API）審査提出（API） 1. ビルド番号のインクリメント App Store Connectは同じビルド番号のアップロードを拒否する。CURRENT_PROJECT_VERSION を上げる必要がある。 XcodeGenを使っている場合は project.yml を編集する： # project.yml settings: base: MARKETING_VERSION: "1.1.0" CURRENT_PROJECT_VERSION: "4" # 3 → 4 に変更ポイント: マーケティングバージョン（1.1.0）はユーザーに見えるバージョン番号、ビルド番号（4）は同一バージョン内の連番。不具合修正の再提出など、ユーザーから見た変更がない場合はビルド番号だけ上げればよい。 2. アーカイブ・アップロード # 環境変数を設定 export APP_STORE_API_KEY="YOUR_KEY_ID" export APP_STORE_API_ISSUER="YOUR_ISSUER_ID" # XcodeGenでプロジェクト再生成 xcodegen generate # アーカイブ xcodebuild archive \ -project KotenOCR.xcodeproj \ -scheme KotenOCR \ -archivePath build/KotenOCR.xcarchive \ -destination "generic/platform=iOS" \ -quiet # IPA書き出し xcodebuild -exportArchive \ -archivePath build/KotenOCR.xcarchive \ -exportPath build/export \ -exportOptionsPlist scripts/ExportOptions.plist \ -quiet # App Store Connectへアップロード xcrun altool --upload-app \ --type ios \ --file build/export/KotenOCR.ipa \ --apiKey "$APP_STORE_API_KEY" \ --apiIssuer "$APP_STORE_API_ISSUER" 注意: xcrun altool に渡す環境変数は export しておく必要がある。source .env だけではサブプロセスに渡らない。 ...

2026年3月11日 · 更新: 2026年3月14日 · 4 分 · Nakamura

App Store Connect APIでiOSアプリにチップ（Tip Jar）機能を追加する完全ガイド

TL;DR iOSアプリにチップ（Tip Jar）機能を追加した。SwiftUI + StoreKit 2 でアプリ側を実装し、App Store Connect REST API を使って商品登録・ローカライズ・価格設定・審査用スクリーンショット・配信地域設定・TestFlight配信までをコマンドラインから完了させた。本記事ではその全手順を再現可能な形で記載する。前提: App Store Connect APIだけでiOSアプリを審査提出する完全ガイドの続編として、APIキーの取得・JWT生成は既にセットアップ済みとする。全体の流れアプリ側の実装（StoreKit 2 + SwiftUI） App Store Connect APIで商品登録（3つの消費型アイテム）ローカライズ設定（日本語・英語）価格設定（$0.99 / $2.99 / $6.99）審査用スクリーンショットのアップロード配信地域の設定有料アプリ契約の締結 TestFlightでの動作確認 1. アプリ側の実装 1.1 StoreKit設定ファイル Xcodeのテスト環境用に TipJar.storekit を作成する。これによりシミュレータでStoreKitのテストが可能になる。 { "products" : [ { "displayPrice" : "0.99", "familyShareable" : false, "internalID" : "tip_small_001", "localizations" : [ { "description" : "開発を応援する小さなチップ", "displayName" : "小さな応援", "locale" : "ja" }, { "description" : "A small tip to support development", "displayName" : "Small Tip", "locale" : "en_US" } ], "productID" : "com.example.app.tip.small", "referenceName" : "Small Tip", "type" : "Consumable" } ] } XcodeGen を使っている場合は project.yml の scheme に StoreKit 設定を追加する： ...

2026年3月10日 · 7 分 · Nakamura

App Store Connect APIだけでiOSアプリを審査提出する手順

TL;DR App Store Connect の REST API を使い、コマンドラインからiOSアプリの審査提出に必要なほぼ全作業（メタデータ・スクリーンショット・年齢レーティング・ビルド紐付け・URL設定・暗号化コンプライアンス・価格設定）を完了させた。本記事ではその手順を再現可能な形で記載する。注意: 「App Privacy（アプリのプライバシー）」のデータ使用状況の宣言だけは、2026年3月時点でAPIが提供されておらず、App Store Connectのブラウザから設定する必要がある。前提条件 Apple Developer Program に登録済み App Store Connect で API キーを発行済みアプリの Bundle ID が登録済み Xcode でアーカイブ・アップロード済みのビルドが存在する（xcodebuild -exportArchive でアップロード可能） Python 3 + PyJWT + cryptography がインストール済み pip install PyJWT cryptography 1. API キーの準備 1.1 API キーの発行 App Store Connect → ユーザーとアクセス → 統合 → App Store Connect API から新しいキーを発行する。名前: 任意（例: deploy-key）アクセス: Admin（メタデータ更新・提出に必要）発行後、以下の情報をメモする：項目説明 Key ID APIキーの識別子（10文字程度の英数字） Issuer ID 組織の識別子（UUID形式）ダウンロードした .p8 ファイルは安全な場所に保存する（一度しかダウンロードできない）： ...

2026年3月5日 · 8 分 · Nakamura