〜エンジニア経験ゼロの元テレビディレクターが、AIと組んで自作アプリを世界に無料公開するまで〜
この文書は、映像ディレクターの池本翔（合同会社スタジオパッチ代表）が、AI（Claude）と協働して「無料の動画文字起こしツール PATTI SCRIBE」を開発し、GitHub で世界に公開するまでの全工程を、クリック単位で記録した手順書である。
プログラミングの専門知識は不要だった。使ったのは「日本語で要望を伝える力」と「実際に触って不具合を報告する力」だけ。物語の骨子として、あるいは同じことに挑戦したい人の実践マニュアルとして使えるよう、事細かに残す。
登場する「役割分担」を先に整理しておく。
| 登場人物 | 役割 | たとえるなら |
|---|---|---|
| 本人（池本） | 要望を出す・実機で試す・不具合を報告する・最終判断する | 施主（依頼主） |
| Claude（チャット） | 設計する・コードを書く・戦略を立てる | 設計士 |
| Claude Code | 本人のPC内で実際にファイルを組み立てる | 現場の大工 |
| GitHub | 完成品を世界に公開する場所 | 公共の掲示板／土地 |
最初の動機は明快だった。テレビ番組・YouTube編集の現場で、インタビューや対談を毎回「文字起こし」する作業に膨大な時間を奪われていた。 クラウドの文字起こしサービスは便利だが、月額料金がかかり、何より「放送前の素材を他社のサーバーに送る」ことへの不安が拭えなかった。
→ 教訓：作るべきものは「自分が心底ほしいもの」から生まれる。 市場調査より前に、自分の痛みがあった。
専門用語は一切使わなかった。伝えたのはこれだけ：
「動画データや音声データから声を抽出してテキストにしたい。YouTubeのURLからも文字起こししたい。この2つを叶えるアプリを作ってほしい」
ポイントは「何を実現したいか」だけを日本語で伝えたこと。「Pythonで」とか「Whisperを使って」といった指定は一切していない。手段はAIが選ぶ。人間は目的を語るだけでいい。
AIが裏側で選定した構成（本人は仕組みを理解する必要はなかったが、記録として）：
これらはすべて無料・オープンソース。だから完成品も無料で配れた。
開発は「本人が実機で試す → 不具合を具体的に報告する → AIが直す」のループでひたすら進んだ。これが最も重要な工程なので、実際に起きたやり取りを時系列で残す。
| Ver | 何を直したか | きっかけとなった本人の報告 |
|---|---|---|
| v1.0 | 初版完成 | — |
| （bat文字化け） | 起動ファイルの文字コード修正 | 「ターミナルに『繝ｩ繧､繝悶Λ』みたいな文字化けが出る」 |
| v1.2 | 冒頭の声が消える問題／速度改善 | 「00:02-00:30の音声が一切テキスト化されてない」 |
| v1.3 | 結果が入れ替わらないバグ修正／16ch対応 | 「2つ目のデータを入れたのに1つ目の結果が表示されたまま」 |
| v1.5 | L/Rペア収録の話者を1人と正しく認識 | 「1&2chがAさん、3&4chがBさんで編集してる」 |
| v1.6 | マルチストリーム動画の音声を全部読む | 「やっぱり冒頭がおかしい」 |
| v1.8 | 冒頭の声の欠落を根絶（無音クッション） | 「同じ音源で、まだ00:00-00:03が拾えてない」 |
| v1.9 | EDIUSテロップ自動生成を追加 | 「EDIUSに文字起こしを貼ってテロップ自動生成できる？」 |
| v1.10 | 1行の最大文字数で自動改行 | 「1行〇文字以上になったら改行したい」 |
| v1.11 | テロップのフォント化け＆クラッシュ修正 | 「クイックタイトラーが固まって落ちた」 |
| v1.12 | テロップのセンター配置＋座標固定 | 「テロップをセンターに来るようにしたい」 |
| v1.13 | ロゴを実アートワークに差し替え | 「マイクマークを添付のロゴに変えて」 |
→ 教訓：本人の仕事は「コードを書くこと」ではなく「現場のプロとして正確に不具合を報告すること」だった。 「00:02-00:30が消えた」という具体的な報告が、AIに原因（音声チャンネルの問題）を特定させた。曖昧な「なんか変」ではなく、時間・症状・再現条件を添えた報告が開発を加速させた。
途中で本人が「みやもさん音.wav」という実際のインタビュー素材を渡した。これが決定的だった。AIはそのファイルを解剖し、「4チャンネル収録で、冒頭28秒は特定チャンネルにしか声が入っていない」ことを数値で突き止めた。
→ 教訓：推測で直すより、現物を渡す方が100倍速い。 困った素材があれば、それ自体をAIに渡す。
自分用には「YouTube文字起こし機能」があった。だが公開版ではこれを外す判断をした。理由：
→ 教訓：「自分が使う」と「他人に配る」は、法的にもリスク的にも別物。 公開版では機能を引き算する勇気が要る。
混乱を避けるため、最終的に用途別の3フォルダに再編成した：
| フォルダ | 役割 | 置き場所 |
|---|---|---|
| ① 自分用 | 毎日使う（YouTube機能付き） | apps\patti-scribe |
| ② 公開版マスター | 公開版の原本＋運営書類（金庫） | apps\patti-scribe-master |
| ③ GitHub用 | 公開作業の当日セット | デスクトップ（作業後は消す） |
→ 教訓：「日常」「保管」「作業」で物理的にフォルダを分けると、頭が混乱しない。
当初の公開版は「Pythonというソフトを別途インストールしてから」動く仕様で、一般ユーザーにはハードルが高かった。そこでPython本体ごとアプリに同梱した「ポータブル版」を作った。
これは Claude Code（現場の大工）の仕事だった。本人が出した指示は実質1行：
「CLAUDE_CODE_BUILD.md を読んで、その通りにポータブル版をビルドして」
結果、「解凍して PattiScribe.bat をダブルクリックするだけ」で起動する232MBのzipが完成した。
→ 教訓：難しい製造作業は Claude Code に丸投げできる。人間は「指示書のありか」を伝えるだけ。
ここが最も「クリック単位」で知りたい部分。実際の画面遷移をそのまま残す。
※本人は既にアカウント（ユーザー名 ikemotodir）を持っていたため、この工程は省略できた。これから作る人向けに手順を残す。
→ ポイント：ユーザー名は変更可能だが、変えると配布URLが全部変わってしまう。最初に決め切る。SNSと統一されているならそのまま活かすのが賢い。
patti-scribe と入力git init などのコマンドは全部無視でOK）config.json（広告・更新通知のリモコン設定）index.html（配布ページ本体）patti_logo.png（ロゴ画像）→ ポイント：ドメイン料もサーバー代も一切かからない。GitHubの「間借り住所」を無料で使える。BASEやCanvaでサイトが作れるのと同じ仕組み。
github.com/ikemotodir/patti-scribe/releases/new を打つ）v1.0 と入力 →「Create new tag: v1.0」を選択PATTI SCRIBE v1.0 と入力PATTI_SCRIBE_portable.zip（232MB）をドラッグ→ これで世界中の誰でもダウンロードできる状態になった。
配布ページのダウンロードボタンを、上げたzipに繋ぐ。
① zipのURLを取得
1. Releaseページで PATTI_SCRIBE_portable.zip のリンクを右クリック
2. 「リンクのアドレスをコピー」を選択
→ https://github.com/ikemotodir/patti-scribe/releases/download/v1.0/PATTI_SCRIBE_portable.zip
② config.json に貼る
1. リポジトリトップ →「config.json」をクリック → 右上の鉛筆マーク（✏️）
2. "download_url": "..." の ... 部分をコピーしたURLに書き換え（★ダブルクォート " の中身だけ）
3. 「Commit changes」
③ index.html に貼る
1. リポジトリトップ →「index.html」をクリック → 鉛筆マーク
2. Ctrl+F で #DOWNLOAD_URL_HERE を探し、同じURLに書き換え
3. 「Commit changes」
→ これで配布ページの緑のダウンロードボタンが機能する。公開完了。
このプロジェクトの本質は「一度で完璧を目指さず、出してから直す」だった。実際に起きたバグと、その対処フローを残す。
本人が実践した、AIに最速で直させる報告の型：
→ この4点セットがあれば、AIは推測ではなく原因を論理的に特定できた。
公開直後、本人が「自分が最初のユーザー」として通しで使い、5つの不具合を発見： 1. ダウンロード後に何をすればいいか分からない → READMEへの案内を追加 2. READMEが開けない → メモ帳で開ける.txt形式に変更 3. ショートカット作成が文字化けエラー → 正しい文字コードで作り直し 4. 文字起こしでcublasエラー → GPU「点火テスト」でCPUへ確実に切替 5. 黒い画面が怖い＆残る → 起動時に自動最小化
→ 教訓：これは「ドッグフーディング」（自社製品を自分で使う品質検査）という正式な手法。公開当日にやったから、実ユーザーが被害に遭う前に直せた。
修正版zipを作った後、GitHub上で差し替える手順（URLを変えずに中身だけ更新）：
① Releaseのzip差し替え 1. Releaseページ（v1.0）→ 右上の鉛筆マーク（Edit） 2. Assets欄の古いzipの右のゴミ箱アイコンをクリック（「will be deleted」と赤字が出る＝削除予約） 3. 新しいzip（同じファイル名）をドラッグ → アップロード100%待ち 4. 緑の「Update release」をクリック → 同名だからダウンロードURLが変わらない＝config.jsonの再編集が不要
② index.htmlの差し替え 1. リポジトリトップ →「Add file」→「Upload files」 2. 新しい index.html をドラッグ（同名なので自動上書き） 3. 「Commit changes」 4. 1〜3分待って Ctrl+F5 でページ更新を確認
→ ポイント：ファイル名を同じにしておくと、差し替えても配線を直す必要がない。この設計が後の運営を劇的に楽にした。
| Claude（チャット） | Claude Code | |
|---|---|---|
| 役割 | 設計・戦略・コード執筆 | 本人のPC内で実際にファイルを組み立てる |
| たとえ | 設計士 | 現場の大工 |
| 得意なこと | 考える・書く・判断する | Python同梱・ffmpeg同梱など「重い製造」 |
〇〇.md）を作成するapps フォルダ内に配置するポータブル版のビルド時：
C:\Users\studi\Desktop\Claude\apps\patti-scribe-master\CLAUDE_CODE_BUILD.md
を読んで、その通りにポータブル版（Python同梱・ダブルクリック起動）を
ビルドして。完成したら結果をMORNING.mdに書いて。
バグ修正（hotfix）時：
patti-scribe-master\hotfix\CLAUDE_CODE_HOTFIX.md を読んで、
その通りに実行して。files内の3ファイルは編集禁止・バイナリコピーのみ。
完了したらMORNING.mdに結果を書いて。
ビルド中、Windowsの「パスが長すぎる」制限にぶつかった際、Claude Code は自力で「短いパスのフォルダで作業し直す」という回避策を実行した。また、セキュリティソフト（Avast）が通信を妨害した際は、既にPCにあったキャッシュを使ってテストを完遂した。
→ 教訓：現場で予期せぬ問題が起きても、Claude Code はある程度自力で解決する。ただし最終判断と検品は人間（と設計士Claude）が担う。
エンジニア経験ゼロの映像ディレクターが、以下をやり遂げた：
プログラミングは書いていない。書いたのは「要望」と「不具合報告」と「判断」だけ。
これは特別な才能の話ではなく、「作りたいものが明確にあり」「実際に手を動かして試し」「AIに正確に伝える」 ことができれば、誰にでも再現できる時代の証明である。
| ツール | 役割 | 料金 |
|---|---|---|
| Claude（チャット） | 設計・コード執筆 | 有料プラン |
| Claude Code | PC内での製造 | 有料プラン |
| GitHub | 公開・配布 | 無料 |
| GitHub Pages | 配布ページのホスティング | 無料 |
| Whisper / ffmpeg / Streamlit 等 | アプリの部品 | 無料（オープンソース） |
| 配布したツール（PATTI SCRIBE） | ユーザーの利用 | 無料 |
🎙️ PATTI SCRIBE © 2026 STUDIO PATTI LLC｜合同会社スタジオパッチ 配布ページ：https://ikemotodir.github.io/patti-scribe/