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

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

ジャパンサーチ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

Apple Sales Reports APIのデータ反映時刻とYouTube APIのクォータリセットを実測した

外部APIを使って日次のデータ取得を自動化する場合、「いつデータが利用可能になるか」「いつクォータがリセットされるか」を把握しておくとスケジューリングに役立ちます。この記事では、Apple App Store Connect Sales Reports APIとYouTube Data API v3について、実際に観測したタイミングを記録します。 Apple App Store Connect Sales Reports API 公式ドキュメントの記載 Appleの公式ドキュメントでは、日次の売上レポートは翌日の太平洋時間午前8時まで（by 8:00 AM Pacific Time）に利用可能になるとされています。参照: Sales and Trends Reports Availability - Apple Developer 実測結果 2026年3月22日に、前日（2026年3月21日）分のデータがいつ取得可能になるかを1時間ごとに確認しました。 16:00 JST (0:00 PT) → 取得不可 17:00 JST (1:00 PT) → 取得不可 18:00 JST (2:00 PT) → 取得不可 19:00 JST (3:00 PT) → 取得不可 20:00 JST (4:00 PT) → 取得不可 21:09 JST (5:09 PT) → 取得可能今回の計測では、太平洋時間の午前5時頃（日本時間 21時頃）にデータが利用可能になっていました。公式に記載されている午前8時よりも約3時間早いタイミングです。 ...

2026年3月22日 · 1 分 · Nakamura

DH（デジタル人文学）ツール情報の自動収集・記事生成システムの構築

DH分野のツール情報を追いかけるデジタル人文学（DH）の分野では、OCR、IIIF、テキスト翻刻といった領域で新しいツールが継続的に開発されています。NDL（国立国会図書館）の ndl-lab や CODH（人文学オープンデータ共同利用センター）などの機関がGitHub上でツールを公開しており、研究者個人による開発も活発です。こうした情報を体系的に収集し、カレントアウェアネスのように定期的にまとめる仕組みが欲しいと考え、自動収集・記事生成のシステムを構築しました。収集対象情報源は3種類です。 X (Twitter) では、DH分野で活発にツールを開発・公開している研究者や機関のアカウントを対象にしています。 RSSフィードでは、カレントアウェアネス・ポータル（国立国会図書館）の https://current.ndl.go.jp/rss.xml を取得しています。 GitHub では、DH関連のツールを公開している組織・個人の公開リポジトリの更新情報を GitHub API 経由で取得しています。方法の検討 X投稿の取得 X の投稿取得にはいくつかの方法を検討しました。方法費用結果 X API (Basic) $100/月確実だが高コストのため不採用 Web検索（site:x.com/xxx）無料インデックスされたごく一部しか取れず不採用 RSSHub（セルフホスト）無料 Xの内部API経由で全ツイート取得可能。Docker運用が必要で、GitHub Actions内での一時起動も検討したが、Playwright案のほうがシンプルなため不採用 Playwright（ログインなし）無料一部アカウントで0件。ログインウォールに阻まれ不採用 Playwright（Cookie認証）無料全アカウントで取得成功。毎日の取得であれば取りこぼしも少ない。採用最終的に、Playwright で Cookie 認証を使う方法を採用しました。DevTools から auth_token と ct0 を手動で取得し、.x_cookies.json に保存する形です。GitHub Actions 上では Secret TWITTER_COOKIE から環境変数として渡しています。 Playwright による自動ログインも試みましたが、X のボット検出で失敗したため、手動取得に落ち着きました。Cookie は数ヶ月で期限切れになるため、定期的な更新が必要です。 AI要約・記事生成方法費用結果 Claude Code 内で手動実行プラン内自動化できないためテスト用のみ Claude API (Anthropic直接) 従量課金動作するが独自のAPI Key管理が必要で不採用 OpenRouter 従量課金複数モデル選択可能、1回$0.05程度で採用 RSSフィードカレントアウェアネス・ポータルでは /feed エンドポイントがアイテム0件で、/rss.xml に30件のアイテムがあることを確認し、後者を使用しています。CODH のサイトはメンテナンス中でRSS取得ができなかったため、X 投稿で代替しています。 ...

2026年3月21日 · 2 分 · 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

researchmapの科研費と業績の紐付けをPlaywrightで自動化した

はじめに researchmap は、日本の研究者が業績を管理・公開するためのプラットフォームです。論文や講演などの業績を登録するだけでなく、科研費（共同研究・競争的資金等の研究課題）との紐付けを行うことで、研究課題ごとの成果一覧を集約できます。この紐付けについて、APIやCSVインポートでの一括設定ができないか調べたところ、調査した限りでは現時点ではWeb UIからの手動操作に限られるようでした。そこで、Playwrightによる自動化を試みました。紐付けの方法を調べる researchmapでは、業績データの一括登録はJSONLやCSVファイルのインポートで可能です。一方、科研費と業績の紐付けについては、調査した限り、一括インポートでは設定できないようでした。 API設計書での確認 researchmap v2 API設計書を確認すると、以下のフィールドはすべて「更新不可」と記載されています。 research_projects（科研費）側： rm:published_paper_id（紐づいた論文の業績ID）→ 更新不可 rm:presentation_id（紐づいた講演の業績ID）→ 更新不可 rm:work_id（紐づいたWorksの業績ID）→ 更新不可業績（論文・講演等）側： rm:research_project_id（紐づいた科研費ID）→ 更新不可実際に検証念のため、JSOLNインポートで identifiers.research_project_id を指定して検証しました。 {"insert":{"type":"presentations","id":"52101757"},"merge":{"identifiers":{"research_project_id":["51361068"]}}} 結果：インポート自体は「完了」と表示されましたが、紐付けは反映されませんでした。このフィールドは無視されるようです。 Web UIでは可能一方、researchmapのWeb UI（編集画面）では、業績ごとに「共同研究・競争的資金等の研究課題」のプルダウンから科研費を選択して紐付けることができます。この操作は1件ずつ手動で行う必要があり、件数が多いと手間がかかります。 Playwrightで自動化する Web UIでの手動操作を、Playwrightを使って自動化するPythonスクリプトを作成しました。仕組み .env ファイルからresearchmapのログイン情報を読み込み Playwrightでブラウザを起動し、自動ログイン各業績の編集ページ（/{slug}/{type}/{id}/edit）に移動 selectize.jsで実装されたプルダウンから、対象の科研費を自動選択「決定」ボタンをクリックして保存既に紐付け済みの業績は自動スキップ編集画面のHTML構造 researchmapの編集画面では、科研費のプルダウンはselectize.jsで実装されています。 <select name="data[PublishedPapersIndex][_source][identifiers][research_project_id][]" class="form-control selectized" multiple="multiple" style="display: none;"> <option value="50040755" selected="selected">TEIを中心とした高度な歴史テキスト構築</option> </select> 実際の <select> は非表示で、selectize.jsが生成するカスタムUIで操作します。Playwrightでは以下のようにselectize入力をクリックし、ドロップダウンからオプションを選択します。 # selectize の入力エリアをクリックしてドロップダウンを開く selectize_input = page.locator(f'#{selectize_id}-selectized') await selectize_input.click() # ドロップダウンから該当の科研費を選択 option = page.locator(f'.selectize-dropdown .option[data-value="{project_id}"]') await option.click() # 「決定」ボタンで保存 submit = page.locator('button[name="save"][type="submit"]') await submit.click() 紐付け設定ファイル紐付け対象はJSONファイルで管理します。 ...

2026年3月19日 · 1 分 · Nakamura

Claude Codeの並列エージェントで882本のブログ記事から解説動画を自動生成した話

はじめに筆者は技術ブログを882本（日英バイリンガル）運営しています。これらの記事をYouTube動画として展開するため、Claude Codeの並列エージェント機能とVOICEVOX音声合成を組み合わせた自動動画生成パイプラインを構築しました。結果として、Claude Codeの週間利用制限（全ユーザーの上位2%が該当）に到達するという珍しい体験をしたので、パイプラインの構成と実績を共有します。パイプラインの全体像ブログ記事 (.md) ↓ Claude Code 並列エージェント (10本同時) 対話台本 (sections.json) ↓ VOICEVOX × 3並列ワーカー解説動画 (video.mp4) ↓ YouTube API YouTube公開 1. 台本生成（Claude Code）各記事を読み込み、2キャラクターの掛け合い形式の台本（sections.json）を生成します。Claude CodeのAgentツールを使い、10本のエージェントを同時に起動して並列処理します。 [ { "section_title": "セクション名", "slide_points": ["スライドに表示するポイント1", "ポイント2"], "lines": [ {"speaker": "usagi", "text": "カタカナヨミアゲテキスト", "display_text": "画面表示テキスト"}, {"speaker": "sora", "text": "カタカナヨミアゲテキスト", "display_text": "画面表示テキスト"} ] } ] text: VOICEVOX読み上げ用（英語技術用語はカタカナ表記） display_text: 画面表示用（英語技術用語はそのまま） 1記事あたり6〜10セクション、各セクション6〜8セリフ 2. キャラクターペアシステム 4組のVOICEVOXキャラクターペアを用意し、記事ごとにローテーションで割り当てます。ペアID 質問役解説役スタイル zundamon_metan ずんだもん四国めたん素朴×丁寧 tsumugi_kiritan 春日部つむぎ冥鳴ひまりギャル×クール usagi_sora 中国うさぎ九州そら控えめ×おっとり hau_whitecul 雨晴はう WhiteCUL 元気×知的立ち絵素材は坂本アヒルさんの素材を使用しています。 ...

2026年3月12日 · 2 分 · Nakamura

Three.js + Puppeteer で VRM キャラクターを動かして動画を自動生成する

はじめに技術ブログの記事を VTuber 風の解説動画に自動変換できたら面白いのでは――そんな思いつきから、Three.js + Puppeteer で VRM キャラクターをフレーム単位でレンダリングし、VOICEVOX の音声とリップシンクさせて動画を生成するパイプラインを作りました。この記事では、実装で得られた知見とハマりどころを共有します。全体のパイプライン処理の流れは以下の通りです。 Markdown 記事を読み込み → LLM（OpenRouter API）でセクション分割された台本を生成 VOICEVOX でセクションごとに音声（WAV）と音素タイミングを生成 Three.js + @pixiv/three-vrm でヘッドレス Chrome 上に VRM モデルを描画し、音素データに基づくリップシンクアニメーションをフレーム連番 PNG として出力スライド画像を自動生成（HTML → Chrome ヘッドレス → PNG） FFmpeg でスライド背景 + VRM アニメーション + 音声を合成し、MP4 動画を出力 Python スクリプトがオーケストレーション役を担い、VRM レンダリングは Node.js スクリプトを子プロセスとして呼び出す構成です。使用技術役割技術 3D レンダリング Three.js v0.172 VRM 読み込み @pixiv/three-vrm v3.3.3 ヘッドレスブラウザ puppeteer-core (SwiftShader) 音声合成 VOICEVOX Engine (Docker) 動画合成 FFmpeg パイプライン制御 Python VRM モデル AvatarSample_C (VRoid Hub / 無料ライセンス) ヘッドレス Chrome で VRM を読み込む課題: file:// の CORS 制限最初の壁は、ヘッドレス Chrome 上で VRM ファイルを読み込む方法でした。ローカルの .vrm ファイルを file:// プロトコルで読もうとすると CORS エラーで弾かれます。 ...

2026年3月9日 · 5 分 · Nakamura

GitHub File History Analyzerの紹介：ファイル編集履歴をAIで分析するツール

本記事はAIが作成しました。はじめに GitHubリポジトリで管理されているファイルの編集履歴を分析したいと思ったことはありませんか？特に長期間にわたって更新されているファイルの変更パターンや、プロジェクトの進化の過程を理解したい場合があります。 GitHub File History Analyzerは、このようなニーズに応えるために開発したコマンドラインツールです。ツールの概要このツールは以下の機能を提供します： GitHubのAPIを使用して特定ファイルのコミット履歴を取得変更内容の統計的な分析（追加・削除行数、変更タイプの分類など） OpenRouter経由でAI（Gemini 2.5 Proなど）による編集パターンの分析分析結果のMarkdown/JSON形式での出力開発の背景デジタルアーカイブプロジェクトで、XMLファイルの長期的な編集作業を追跡する必要がありました。単純なgit logでは得られない、より深い洞察（編集の傾向、作業の質、進捗状況など）を得たいという要求から、このツールの開発に至りました。技術的な実装使用技術言語 : Python 3.8+ 主要ライブラリ : PyGithub（GitHub API wrapper） requests（HTTP通信） python-dotenv（環境変数管理）アーキテクチャツールは主に2つのコンポーネントで構成されています： GitHubFileHistoryAnalyzer : GitHub APIを使用してファイル履歴を取得・分析 OpenRouterClient : AI分析のためのクライアント # 基本的な使用例 analyzer = GitHubFileHistoryAnalyzer(github_token) commits = analyzer.get_file_history("owner/repo", "path/to/file.xml") analysis = analyzer.analyze_patches(commits) prompt = analyzer.generate_ai_prompt(commits, analysis) 実際の使用例基本的なコマンド # ファイル履歴の取得と表示 python main.py --repo owner/repo --file path/to/file.py # AI分析の実行 python main.py --repo owner/repo --file path/to/file.py --analyze # 結果をMarkdown形式で保存 python main.py --analyze --ai-output analysis.md 分析結果の例ツールは以下のような情報を提供します： ...

2025年7月24日 · 更新: 2025年7月24日 · 1 分 · Nakamura