AI MEDIA

タグ: AI編集部

  • AIで編集部を作るには?制作・記録・公開のFAQ

    AIで編集部を作るには?制作・記録・公開のFAQ

    AI編集部の作り方を理解するためのポイント

    まず、目的を決めます。次に、条件を確認します。

    その後、必要な情報を集めます。また、作業順も整理します。

    はじめに、現在の状態を記録します。続いて、一つずつ設定します。

    ただし、一度に変更し過ぎないでください。そのため、各操作の結果を確かめます。

    問題があれば、直前の変更を見直します。そして、原因を切り分けます。

    さらに、別の端末でも確認します。一方、推測だけでは判断しません。

    また、重要な条件は公式情報で調べます。特に、料金や仕様は再確認します。

    最後に、公開状態を確認します。あわせて、個人情報も見直します。

    • 準備内容を確認する
    • 変更点を記録する
    • 実際の動作を確かめる

    以上を順番に進めます。これで、作業の抜けを減らせます。

    AI編集部の作り方では、素材収集、下書き生成、人間のレビュー、公開判断を役割分担します。また、AI編集部の作り方を工程ごとに決めると、品質と安全性を管理しやすくなります。

    AI編集部の作り方と基本工程

    まず、AI編集部の作り方では、AIの担当範囲と人間の承認箇所を明文化します。また、AI編集部の作り方を検討するときは、OpenAIヘルプセンターなど利用製品の公式情報も確認してください。

    AIに文章を書かせるだけでは、継続的なメディア運営にはなりません。

    今回の制作記録から見えてきた結論は、AIを単独のライターとして使うのではなく、制作、記録、編集、公開を支える「編集部」の一部として使うことです。

    AIに記事を書かせる前に、AIが記事を書く環境を作った。RELATED ARTICLE  |  AIAIに記事を書かせる前に、AIが記事を書く環境を作った。AIに記事を書かせるだけなら、APIをつないでプロンプトを渡せば終わると思っていた。AI◷ 10 min

    実際の録画では、AI Mediaのルールとして「公開につながる操作は、デバイスを問わず記録する」という方針が整理されていました。MacでもiPhoneでも、記事になるかを先に判断せず、まず素材を残します。

    AIに記事を書かせたら、最後に残ったのは人間の違和感だった。RELATED ARTICLE  |  AIAIに記事を書かせたら、最後に残ったのは人間の違和感だった。それなら完成しているはずだった。ところが実機で開くと、サムネイルは一枚も見えない。情報を追加した画面は横へ広がり、本文は細く押しつぶされている。直すためにタブへ分けたら、今度はウィンドウの中身が真っ白になった。AI◷ 7 min

    公開につながる操作はデバイスを問わず録画するというAI Mediaのルール
    AI Mediaでは、記事になるかどうかを撮影前に選別せず、公開につながる操作をMac・iPhoneともに記録します。あとから一次素材として再利用するための基本ルールです。

    今回確認した録画は約2分45秒です。そこから6枚のスクリーンショットが抽出され、5枚が採用候補になり、3本の記事候補が作られています。一つの短い録画でも、制作工程を残しておけば複数の企画へ展開できることが分かります。

    導入前の質問

    AIで編集部を作るとは、どういう意味ですか?

    AIに記事を一本書かせることではありません。

    制作記録に残されたコンセプトでは、AIを使って次の工程をつなげることが目標になっています。

    • 作る
    • 記録する
    • 編集する
    • 公開する
    AI Media Design ConceptでAIが作る・記録する・編集する・公開すると整理した画面
    AIを単なる文章生成ツールではなく、「作る・記録する・編集する・公開する」の全工程を支える編集部として位置づけたコンセプトです。

    AIによる文章生成は、その中の一工程にすぎません。画面録画、スクリーンショット、作業結果、失敗、次にやることを残し、それらを記事やガイドへ再構成できる状態にすることが重要です。

    完成していない作業も記録する必要がありますか?

    必要です。

    今回の素材では、完成品だけではなく「ブランドが育っていく過程を公開する」という考え方が示されています。

    たとえばロゴ制作なら、完成したロゴだけを見せるのではなく、次の流れを残します。

    1. 今日の目的
    2. 実際に行った作業
    3. 作業終了時点の結果と感想
    4. 次回やること

    録画内では「今日はロゴのタイポグラフィまで完成した」「次回は子テーマへ実装する」という例が使われていました。結果だけでなく、次の作業へ続く文脈まで残すことで、後から自然なストーリーとして記事化できます。

    ブランドを作る作業をそのまま記事にするAI Mediaの制作記録
    ブランド制作の作業を記録しておけば、完成品だけでなく、判断や試行錯誤の過程も記事資産として公開できます。

    設定中の質問

    画面収録には何を入れればよいですか?

    制作記録では、最低限次の4項目を残す方針になっています。

    • 今日の目的
    • 実際の作業
    • 終わった時点の感想
    • 次回やること
    画面収録に残す今日の目的・実際の作業・感想・次回やることの4項目
    録画では「今日の目的」「実際の作業」「終わった時点の感想」「次回やること」の4項目を残します。短い補足でも、後から記事のストーリーを組み立てやすくなります。

    目的と次回作業は、それぞれ30秒程度でも構いません。作業後の感想も長い説明は不要です。

    重要なのは、操作画面だけを無言で残すのではなく、「なぜ始めたのか」「何が終わったのか」「次に何をするのか」を記録することです。

    音声がなくても記事にできますか?

    画面上に十分な文字情報があれば、一定範囲までは記事化できます。

    今回の録画には音声トラックがありますが、実測上はほぼ無音でした。そのため、判断理由や口頭説明を音声から復元することはできません。

    今回の記事では、画面に表示された文章とProjectの制作ログだけを根拠にしています。今後は、作業終了時の感想を音声または短いテキストで残すと、失敗理由や判断の背景まで記事へ反映しやすくなります。

    運用中の質問

    録画をそのまま公開してもよいですか?

    公開前の確認が必要です。

    画面収録には、メールアドレス、管理画面URL、通知、個人名、APIキーなどが映り込む可能性があります。今回のProjectにも、画像を確認してから公開する前提が記録されています。

    安全な流れは次のとおりです。

    1. 画面収録を保存する
    2. 代表スクリーンショットを抽出する
    3. 個人情報や秘密情報を確認する
    4. 必要ならマスキングまたは再撮影する
    5. 記事本文と画像の対応を確認する
    6. 下書きとして保存する
    7. 人間が最終レビューする

    AIが画像を選んだとしても、公開判断まで任せてはいけません。

    失敗した作業も残すべきですか?

    残す価値があります。

    失敗そのものだけでは記事にならなくても、原因の切り分け、やり直した手順、次回の改善点まで記録すれば、トラブルシューティング記事や失敗談として利用できます。

    成功画面だけを集めるより、判断の過程を含めたほうが一次情報としての価値は高くなります。

    費用と安全性

    AIで編集部を作るには、いくらかかりますか?

    今回のProjectには、利用料金や契約プランの記録がありません。そのため、具体的な費用は断定できません。

    公開前には、実際に利用したAIサービス、クラウドストレージ、サーバー、ドメイン、編集ツールについて、公式料金と契約内容を確認する必要があります。

    動画を放り込んだら、AI編集部はどこまで記事を作れるのか。RELATED ARTICLE  |  AI動画を放り込んだら、AI編集部はどこまで記事を作れるのか。動画を一本入れれば、AIが内容を読み、スクリーンショットを選び、記事を書いてくれる。AI◷ 6 min

    確認できていない料金や費用対効果を、推測で本文へ入れるべきではありません。

    AIにどこまで任せてよいですか?

    素材整理、構成案、下書き、関連記事候補の作成には活用できます。

    一方、次の作業は人間による確認が必要です。

    • 事実関係
    • 個人情報
    • 公開権利
    • 最新仕様
    • 料金
    • 画像の公開可否
    • アフィリエイト表記
    • 最終的な公開判断

    AIを編集部として使うことと、公開責任をAIへ渡すことは別です。

    困ったときの確認先

    記事化がうまくいかない場合は、次の順番で確認します。

    • 録画に目的が残っているか
    • 実際の操作が確認できるか
    • 結果と次回作業が記録されているか
    • スクリーンショットだけで操作の流れを説明できるか
    • 失敗や判断理由が残っているか
    • 画像に個人情報が含まれていないか
    • 素材にない情報を本文で補っていないか

    素材が不足している場合は、AIに推測させるのではなく、追加撮影または補足メモを作成します。

    まとめ

    今回の記録で最も重要なのは、「AIで記事を書く」から「AIで編集部を作る」へ視点を変えたことです。

    公開につながる操作を記録し、目的、作業、感想、次回予定を残す。そこから画像と文章を整理し、最後は人間がレビューする。この流れができれば、完成品だけでなく、ブランドを作る過程そのものを記事資産として残せます。

    AIの価値は、一本の文章を自動生成することだけではありません。制作中に生まれた知識を埋もれさせず、次の記事や次の判断へつなげられる状態を作ることにあります。

  • 動画を放り込んだら、AI編集部はどこまで記事を作れるのか。

    動画を放り込んだら、AI編集部はどこまで記事を作れるのか。

    動画を一本入れれば、AIが内容を読み、スクリーンショットを選び、記事を書いてくれる。

    言葉にすると、それほど難しい仕組みには聞こえない。動画をAPIへ渡し、文章を返してもらえば終わりそうだ。僕も最初はそう考えていた。

    実際にAI Media Studioへ動画を入れてみると、文章が出るまでより、その文章を信用できる状態にするまでの方が長かった。今回は、動画が記事候補になり、人間の承認を待つところまでを追ってみる。

    AIに記事を書かせる前に、AIが記事を書く環境を作った。RELATED ARTICLE  |  AIAIに記事を書かせる前に、AIが記事を書く環境を作った。AIに記事を書かせるだけなら、APIをつないでプロンプトを渡せば終わると思っていた。AI◷ 10 min RELATED ARTICLE  |  AI / WORKFLOW AIに記事を書かせる前に、AIが記事を書く環境を作った。 文章生成だけでは終わらない、AI編集環境の設計と制作基盤を振り返ります。 AI MEDIA◷ 8 min2026.07.18

    入口は、動画を置く場所だけにした

    制作の入口はInboxだ。画面収録や動画をドラッグ&ドロップすると、素材が保管場所へコピーされ、処理対象として認識される。

    AI Media StudioのInbox画面
    動画を受け取るInbox。制作フローの入口を一つにした。

    ここで重要なのは、アップロード画面を豪華にすることではない。人間が「この動画を記事にしたい」と判断した後、迷わず処理を始められることだった。

    以前はFinderで動画を探し、コピー先を確認し、コマンドを実行し、ログを見る必要があった。操作が少しずつ分散しているだけでも、毎回やると面倒になる。Inboxは、その面倒を一つの動作へ押し込めるための入口である。

    動画を記事素材へ分解する

    動画を受け取ると、AI Media Studioはプロジェクトを作る。元動画の情報を調べ、代表サムネイルを生成し、記事で使えそうな場面をスクリーンショットとして抽出する。

    AIに記事を書かせたら、最後に残ったのは人間の違和感だった。RELATED ARTICLE  |  AIAIに記事を書かせたら、最後に残ったのは人間の違和感だった。それなら完成しているはずだった。ところが実機で開くと、サムネイルは一枚も見えない。情報を追加した画面は横へ広がり、本文は細く押しつぶされている。直すためにタブへ分けたら、今度はウィンドウの中身が真っ白になった。AI◷ 7 min

    文章を直接生成する前に、まず素材を分解する。これは回り道に見えるが、後から記事を直すときに効いてくる。文章に違和感があれば元動画へ戻れる。説明に画像が必要なら抽出済みの画面を確認できる。AIが何を根拠にしたのか、人間が追える。

    AIで編集部を作るには?制作・記録・公開のFAQRELATED ARTICLE  |  AIAIで編集部を作るには?制作・記録・公開のFAQAIに文章を書かせるだけでは、継続的なメディア運営にはなりません。AI◷ 6 min
    サムネイルが表示されたProjects画面
    各プロジェクトに代表画像が並ぶ。名前だけの一覧より、元動画を判別しやすい。

    サムネイルも最初からあったわけではない。プロジェクト名と状態だけの一覧は、数件なら読める。しかし画面収録が十数件に増えると、文字列だけでは見分けられなくなった。そこでffmpegで代表フレームを作り、既存プロジェクトには後から一括生成した。

    ffmpegとは?Macでインストールして動画を扱う方法RELATED ARTICLE  |  開発環境ffmpegとは?Macでインストールして動画を扱う方法ffmpegは、動画や音声を変換・解析・切り出しできる定番のコマンドラインツールです。名前だけを見ると専門家向けに感じますが、MacではHomebrewを使えば数分で導入できます。この記事では、インストールから開発環境◷ 4 min RELATED ARTICLE  |  MAC / FFMPEG ffmpegとは?Macでインストールして動画を扱う方法 ffmpegの導入から、動画の静止画抽出と自動処理までを説明します。 AI MEDIA◷ 4 min2026.07.19

    文章一枚では、レビューできなかった

    Markdownが生成されると、最初は達成感がある。見出しがあり、段落があり、それらしい結論もある。ただし、それらしいことと正しいことは別だ。

    画面操作の記事なら、説明とスクリーンショットが対応しているか確認しなければならない。個人情報や過去の会話履歴が写っていないかも見る必要がある。元動画のファイル名、解像度、再生時間も確認したい。

    Article Images Sourceタブを備えたAI Media Studioの記事画面
    Article、Images、Sourceを切り替え、文章・画像・元動画を同じプロジェクトで確認する。

    そのため、レビュー画面をArticle、Images、Sourceの三つに分けた。ArticleではMarkdownを読み、必要なら編集する。Imagesでは抽出された全画像を確認する。Sourceでは元動画の情報を見る。

    AIが記事を書いた後、人間が見るべきものを一か所へ集めた形だ。生成ボタンより、こちらの方が実際の運用では重要だった。

    自動化は、きれいには進まない

    もちろん、動画を入れた瞬間からすべてが順調に動いたわけではない。

    macOSのGUIアプリはターミナルのPATHを引き継がず、実機にあるffmpegが見つからなかった。サムネイル生成を実装しても、APIとSwiftUIの境界が合わず、一枚も表示されないことがあった。既存データへの生成は実機でbackfillを実行した。

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

    さらに、情報を右側へ足し続けると本文が細くなった。画像一覧を本文の上へ置くと画面全体が崩れ、タブ化した直後にはコンテンツが真っ白になった。

    タブ化後に真っ白になったAI Media Studio
    タブ化の途中で、ウィンドウだけが残り内容が描画されなくなった。

    テストが通ったことと、実機で使えることは同じではない。AIはコードを速く書けるが、古いアプリを起動していないか、Google Driveが同期しているか、画面が窮屈に感じないかまでは勝手に保証してくれない。

    RELATED ARTICLE  |  AI / DESIGN AIに記事を書かせたら、最後に残ったのは人間の違和感だった。 AIの実装力と、人間が画面を見て判断する役割について掘り下げます。 AI MEDIA◷ 7 min2026.07.18

    AIが作るのは、完成品ではなく判断材料

    現在の流れでは、AI Media Studioが動画を受け取り、素材を整理し、スクリーンショットを抽出し、Markdownの下書きを作る。そこから人間がArticle、Images、Sourceを見比べ、修正するか、再生成するか、却下するか、承認するかを決める。

    つまり、自動化されたのは「公開」ではない。公開するための判断材料を揃えるところまでだ。

    これは期待より控えめな結論に見えるかもしれない。しかし、文章だけを自動生成していたときより、はるかに実用的だった。人間が毎回ゼロから動画を見返す必要はない。一方で、AIの出力を無条件に信じる必要もない。

    動画一本から、記事一本まで

    動画を放り込めば、AI編集部は記事の完成直前まで進める。素材を分け、画像を並べ、下書きを作り、確認すべき場所を人間へ渡す。

    最後の承認だけは、まだ人間の仕事だ。そして今のところ、そこは無理に自動化しなくていいと思っている。

    記事制作で重かったのは、文章を書く行為だけではなかった。素材を探し、画面を切り出し、根拠を確認し、公開してよいか判断することだった。AI Media Studioが目指しているのは、人間を編集部から追い出すことではない。その手前に散らばっていた作業を、一つのデスクへ戻すことである。

    動画一本を入れて、記事一本を確認できるところまで来た。次に試すべきなのは、この流れを一本だけでなく、十本、五十本と続けても破綻しないかどうかだ。

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

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

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

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

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

    動画を放り込んだら、AI編集部はどこまで記事を作れるのか。RELATED ARTICLE  |  AI動画を放り込んだら、AI編集部はどこまで記事を作れるのか。動画を一本入れれば、AIが内容を読み、スクリーンショットを選び、記事を書いてくれる。AI◷ 6 min

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

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

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

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

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

    AIに記事を書かせたら、最後に残ったのは人間の違和感だった。RELATED ARTICLE  |  AIAIに記事を書かせたら、最後に残ったのは人間の違和感だった。それなら完成しているはずだった。ところが実機で開くと、サムネイルは一枚も見えない。情報を追加した画面は横へ広がり、本文は細く押しつぶされている。直すためにタブへ分けたら、今度はウィンドウの中身が真っ白になった。AI◷ 7 min RELATED ARTICLE  |  AI / VIDEO 動画を放り込んだら、AI編集部はどこまで記事を作れるのか。 動画の投入から画像抽出、記事候補、レビューまでの実際の流れを追います。 AI MEDIA◷ 5 min2026.07.18

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

    AIで編集部を作るには?制作・記録・公開のFAQRELATED ARTICLE  |  AIAIで編集部を作るには?制作・記録・公開のFAQAIに文章を書かせるだけでは、継続的なメディア運営にはなりません。AI◷ 6 min

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

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

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

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

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

    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から普通の制作アプリとして起動できる。

    RELATED ARTICLE  |  AI / CODEX ChatGPTとCodexだけでMacアプリを作ってみた ChatGPTとCodexを使い、Macアプリを完成させるまでの実録です。 AI MEDIA◷ 5 min2026.07.19

    僕が欲しかったのは、どこからでも触れるサービスより、普段の制作環境へ自然に収まる道具だった。動画を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のワークスペースを見失ったことがある。ビルドは成功したのに、見ていた実ファイルの場所が違っていたこともある。新しいアプリを作ったつもりで古いアプリを起動し、「直っていない」と悩んだ。

    ChatGPTとCodexだけでMacアプリを作ってみたRELATED ARTICLE  |  制作・開発日誌ChatGPTとCodexだけでMacアプリを作ってみたChatGPTに相談し、Codexにコードを書かせれば、Macアプリはすぐ完成する。始める前は、どこかでそう思っていました。制作・開発日誌◷ 6 min

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

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

    右ペインが狭く崩れたProjects画面
    一覧と本文を横に並べ続けた結果、右ペインが押しつぶされて読みにくくなった。
    タブ化後にコンテンツが真っ白になったAI Media Studio
    タブ化の途中で、タイトルバーと選択バー以外が真っ白になった画面。

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

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

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

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

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

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

    RELATED ARTICLE  |  AI / DESIGN AIに記事を書かせたら、最後に残ったのは人間の違和感だった。 AIの実装力と、人間が画面を見て判断する役割について掘り下げます。 AI MEDIA◷ 7 min2026.07.18

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

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

    AI編集者のためのデスク

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

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

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

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

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

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