制作フローアーカイブ

AIに記事を書かせるだけなら、APIをつないでプロンプトを渡せば終わると思っていた。

実際には、記事を書くコードより先に、記事を書く環境を作ることになった。

最初に欲しかったものは単純だった。動画や画面収録を放り込む。AIが中身を見て、読みやすい記事を書き、Markdownで返す。それなら数本のAPIと、少し気の利いたプロンプトがあれば完成する。少なくとも、作り始める前の僕はそう考えていた。

ところが文章が一度生成された瞬間、その考えは崩れた。文章は出る。でも、どの映像を根拠にしたのか分からない。画像をどこへ入れるのか決められない。修正前の文章が残らない。失敗しても、どこで失敗したのか追えない。

文章を生成できることと、記事を制作できることは、かなり違っていた。

Article Images Sourceタブを備えたAI Media Studioの記事画面 — Article、Images、Sourceを切り替える構成に落ち着いた記事画面。

「文章が出た」の先に何もなかった

最初は、動画一本を入力して記事一本を出力する、小さな変換器を想像していた。入力と出力があればよく、その間はAIに任せればいい、と。

しかし記事を読む側には、AIが何を見て書いたかは関係ない。内容が正しいか、画像が適切か、説明の順番に無理がないか、それだけが残る。生成された文章に違和感があれば、元動画へ戻って確認する必要がある。画面操作を説明するなら、その瞬間のスクリーンショットも必要になる。

すると必要なものが急に増えた。元動画、文字起こし、スクリーンショット、記事構成、Markdown、レビュー、修正履歴、承認状態、そしてログ。どれも文章生成そのものではないが、どれか一つ欠けても安心して記事を外へ出せない。

AIへ「いい記事を書いて」と命令するだけでは足りなかった。AIが参照できる素材があり、判断の途中が残り、失敗した場所を人間が確認できる作業環境が必要だった。

便利なプロンプトを作るつもりが、編集部のデスク、資料棚、進行表、校正フローまで作る話になった。少し大げさに聞こえるが、実装量はむしろ正直だった。

Google Driveを記事素材の保管庫にした

素材と成果物の置き場所にはGoogle Driveを選んだ。Drive上に Inbox、Projects、Review、Archive、Logs、Config を置き、動画、記事、画像、状態をファイルとして残す設計にした。

Inbox に入った素材は処理対象になり、作業中のものは Projects にまとまる。確認が必要な記事は Review、完了後は Archive。動作の記録は Logs、設定は Config にある。実装上の細部は今後も変わるだろうが、少なくとも「何がどこにあるか」を人間がFinderから追える。

すべてを専用クラウドサービスへ預ける方法もあった。その方が設計はきれいだったかもしれない。ただ、サービスが止まった瞬間に自分の記事まで見えなくなる構成にはしたくなかった。

僕が重視したのは、履歴と成果物が自分の手元に残ることだった。記事は article.md として読める。画像は普通の画像ファイルとして開ける。プロジェクトの状態もJSONで確認できる。アプリが壊れても、制作物まで一緒に消えない。Google Driveの同期や版履歴も、復旧手段として使える。

もちろんDriveにも問題はあった。同期が止まり、処理が進まないことがあった。クラウドに置いたから安全、という単純な話ではない。それでも、独自データベースの奥に閉じ込めるより、僕には状況を理解しやすかった。

Webではなく、macOSのデスクにした

最初はWebアプリも検討した。ブラウザで開けて、どこからでも使える。説明もしやすい。

それでも最終的にはSwiftUIのmacOSネイティブアプリにした。Google Driveのローカルフォルダを直接扱え、Finderで素材の場所を開ける。OpenAI API KeyはKeychainに保存できる。ローカルで動き、Dockから普通の制作アプリとして起動できる。

僕が欲しかったのは、どこからでも触れるサービスより、普段の制作環境へ自然に収まる道具だった。動画をFinderから確認し、記事を編集し、必要ならログを見る。その流れにブラウザとアップロード画面を何枚も挟みたくなかった。

ネイティブアプリにすれば楽になるわけではない。むしろmacOS GUIアプリはターミナルの PATH をそのまま引き継がず、実機にあるはずのffmpegとffprobeがDoctorでは not found になった。ターミナルでは動く。アプリでは見つからない。コンピューターは、こちらが暗黙に期待したことを丁寧に裏切る。

そこで実行ファイルをPATHだけに頼らず、Homebrewの固定パスも含めて検出する必要が出た。APIキーも環境変数任せではなくKeychainを優先する設計に変わった。ローカルアプリらしく使うために、ローカルアプリ特有の面倒を見ることになった。

必要性の順番で増えた機能

最初に作ったのはDashboardとDoctorだった。記事を書く前に、Google Drive上の記事素材の保管庫へアクセスできるか、APIは使えるか、ffmpegとffprobeは動くかを確認できなければならない。Doctorは地味だが、失敗を「なぜか動かない」から「ここが動いていない」へ変える。

次にInboxが必要になった。動画を受け取り、処理の入口を一つにするためだ。Projectsでは素材ごとに作業を分け、生成されたMarkdownと状態を追えるようにした。文章ができた後にはReview Queueが必要になった。生成物を人間が読み、approve、reject、regenerateを選べる場所である。

AI Media StudioのInbox画面 — 動画を受け取る入口として作ったInbox画面。素材の処理状況をここから確認する。

記事は眺めるだけでは済まないので、Markdown編集と保存も加わった。修正前へ戻れるように履歴を残し、何が起きたか確認するためLogsも必要になった。OpenAI API Keyの設定画面は、秘密をConfigurationへ露出させず、設定済みかどうかだけを表示する形にした。

動画処理にはffmpegとffprobeを使った。ここで映像から代表フレームを作るサムネイルが欲しくなった。プロジェクト名だけが並ぶ一覧は、件数が増えると見分けにくい。画像一枚があるだけで、どの画面収録だったか思い出せる。

サムネイルが表示されていなかったReview Queue画面 — サムネイル機能を実装したはずなのに、実機では一枚も表示されなかった。

サムネイルが表示されたProjects画面 — 修正後は一覧にサムネイルが並び、画面収録を視覚的に見分けられるようになった。

ところが代表画像一枚では、記事を書く素材として足りなかった。動画から抽出した全スクリーンショットを見たい。しかも本文の近くで見たい。そこでArticle、Images、Sourceのタブを作り、記事、抽出画像、元動画情報を同じプロジェクトの中で切り替えられるようにした。

機能一覧だけを見れば、最初から設計できそうに見える。実際は逆だった。使って、足りないと気づき、追加して、別の場所が崩れる。その繰り返しで形が決まった。

「ビルド成功」は完成の意味ではなかった

開発中、Codexのワークスペースを見失ったことがある。ビルドは成功したのに、見ていた実ファイルの場所が違っていたこともある。新しいアプリを作ったつもりで古いアプリを起動し、「直っていない」と悩んだ。

Google Driveが同期されず処理が止まり、CodexのサンドボックスからGoogle Drive上の保管庫へ書き込めない場面もあった。権限と実行環境が違えば、正しいコードでも動かない。既存プロジェクトへサムネイルを作るbackfillは、実機側で実行した。

サムネイルを一覧へ追加するとレイアウトが崩れた。右へ右へ情報を足した結果、本文が細く押しつぶされた。ならばタブに分けようと変更したら、今度は画面が真っ白になった。ウィンドウと青い選択バーだけが残り、内容は何も描画されない。

右ペインが狭く崩れたProjects画面 — 一覧と本文を横に並べ続けた結果、右ペインが押しつぶされて読みにくくなった。

タブ化後にコンテンツが真っ白になったAI Media Studio — タブ化の途中で、タイトルバーと選択バー以外が真っ白になった画面。

テストが通ること、ビルドが成功すること、実機で気持ちよく使えること。この三つは別々だった。自動化できるのは重要だが、自動化の結果を見る人間までは自動化できない。

AIで開発すれば全部自動で終わる、という期待は早い段階で捨てた。AIはかなり速くコードを書く。しかし、間違った場所に速く到達することもある。画面が崩れているのに仕様上は満たしている、という状況は普通に起きた。

AIが書き、人間が気持ち悪さを拾う

今回、AIはコードを書き、関連箇所を調査し、テストを実行し、修正案を出した。大量のファイルを横断して原因候補を探す作業は得意だった。同じ形式のテストを追加するのも速い。

一方で、人間の仕事は別の場所に残った。

一覧を見て「何か分かりにくい」と感じる。プロジェクト名だけでは判別できないからサムネイルが必要だと気づく。代表画像だけでは記事を書けないので、抽出画像を全部見たいと要求する。右側へ機能を足し続けて画面が窮屈になったら、タブへ分けると決める。そして最後に、その記事を外へ出してよいか承認する。

これらは高度なアルゴリズムではない。むしろ「気持ち悪い」「使いにくい」「ここに欲しい」という感覚に近い。ただ、その感覚が製品の形を決めた。

AI Media StudioはAIが作った、と言うと話が簡単になる。しかし実際は、AIが案を出し、人間が実機で違和感を見つけ、AIが直し、また人間が確認する往復で作られた。どちらか一方だけでは、たぶん文章を吐くデモか、永遠に完成しない設計書になっていた。

AI編集者のためのデスク

AIに記事を書かせる前に必要だったのは、優秀なプロンプトではなかった。

必要だったのは、素材が集まる場所、判断の履歴、画像、記事、レビュー、修正、承認がつながる環境だった。AIが何を見て、どこで失敗し、人間が何を直したかを追えることだった。

もちろん、現時点ですべてが完成したわけではない。各機能の長期運用や、大量プロジェクトでの安定性は今後の検証になる。動画を使わない記事生成で、どの素材構成が最適かも未確認だ。

それでも、最初の思い違いだけははっきりした。記事制作は文章の生成では終わらない。文章の前後にある、素材整理、確認、修正、承認まで含めて初めて仕事になる。

AI Media Studioは、記事を書くアプリというより、AIが編集者として働くためのデスクを作る試みである。

デスクができたので、ようやく最初の記事を書ける。

タグ: 制作フロー

AIに記事を書かせる前に、AIが記事を書く環境を作った。