AIがコードを書き、テストを通し、ビルドまで終えた。
それなら完成しているはずだった。ところが実機で開くと、サムネイルは一枚も見えない。情報を追加した画面は横へ広がり、本文は細く押しつぶされている。直すためにタブへ分けたら、今度はウィンドウの中身が真っ白になった。
エラーは出ていない。テストも落ちていない。それでも、どう見てもおかしい。
AI Media Studioを作る過程で、何度もこの状況に出会った。そして最後まで残った人間の仕事は、コードを書くことより「これは違う」と感じることだった。
RELATED ARTICLE | AIAIに記事を書かせる前に、AIが記事を書く環境を作った。AIに記事を書かせるだけなら、APIをつないでプロンプトを渡せば終わると思っていた。 仕様を満たしているのに、使えなかった
AIへ依頼するとき、僕は要件を書く。Projects一覧へサムネイルを表示する。Project Detailにも同じ画像を出す。Review Queueでも共通利用する。画像は非同期で読み込み、存在しない場合はプレースホルダーを表示する。
RELATED ARTICLE | AIAIで編集部を作るには？制作・記録・公開のFAQAIに文章を書かせるだけでは、継続的なメディア運営にはなりません。
RELATED ARTICLE | AI / CODEX
ChatGPTとCodexだけでMacアプリを作ってみた
ChatGPTとCodexを使い、Macアプリを完成させるまでの実録です。
要件としてはかなり具体的だ。AIは関連コードを探し、APIを追加し、SwiftUIへ画像ビューを組み込み、テストを書く。実装結果だけを読めば、仕事は終わっている。
しかし、実機のProjects画面には画像がなかった。左側には従来どおりプロジェクト名と状態が並び、右側にはMarkdown本文が表示されている。サムネイル用の領域そのものが見当たらない。
コード上の「ある」と、画面上の「見える」は別だった。APIが値を返すこと、Swiftのモデルが値を受け取ること、画像URLが認証を通ること、レイアウト内に表示領域が存在すること。その全部がつながって、ようやく一枚の画像になる。
正しさは、画面の気持ち悪さを検出しない
サムネイルが表示されるようになると、次は抽出したスクリーンショットを全部見たくなった。記事を書くための素材なのだから、代表画像一枚だけでは足りない。
最初は本文の上へ画像一覧を追加した。要求には合っている。ただし画面全体の高さが膨らみ、Markdownを読む場所が不安定になった。次に、右ペインへ情報を足した。今度は横幅が足りなくなった。
機能は増えた。表示もされている。ボタンも押せる。それでも気持ち悪い。
この「気持ち悪い」は、テストケースに書きにくい。画面幅が何ピクセルなら失敗なのか。タイトルが何文字なら窮屈なのか。本文を読む人がどこで疲れるのか。数値へ変換できる部分はあるが、最初に問題を見つけるのは、たいてい視覚的な違和感だった。
タブに分けたら、何も表示されなくなった
横へ増やすのをやめ、Article、Images、Sourceの三つのタブへ分けることにした。記事を読むときはArticleだけを表示する。画像はImagesで独立してスクロールする。元動画の情報はSourceへ置く。
RELATED ARTICLE | AI動画を放り込んだら、AI編集部はどこまで記事を作れるのか。動画を一本入れれば、AIが内容を読み、スクリーンショットを選び、記事を書いてくれる。 考え方は自然だった。実装も通った。ところが新しいアプリを起動すると、タイトルバーと青い選択線だけが残り、コンテンツは真っ白だった。
ここでも「ビルド成功」はほとんど慰めにならなかった。TabViewの初期選択、NavigationSplitViewとの組み合わせ、ObservableObjectの初期化、画像読み込み、MainActor。原因候補を一つずつ外し、まずArticleだけを戻し、その後Images、Sourceを順番に復帰させた。
AIは候補を列挙し、コードを比較し、修正を作るのが速い。一方で、真っ白な画面を見て「前より悪い」と判断するのは人間だった。
人間は、答えより先に違和感を持つ
人間の判断は、いつも説明できる形で始まるわけではない。
「サムネイルが欲しい」と言う前には、文字列だけの一覧が分かりにくいという感覚があった。「画像を全部見たい」と言う前には、代表画像一枚では記事を書けないという不足感があった。「右へ出すのは無理がある」と言ったときも、最初から理想のレイアウトを説明できたわけではない。
まず違和感があり、その後で理由を言葉にする。AIへ修正を頼むのは、その次だ。
AIは明文化された問題に強い。ファイルを探し、影響範囲を調べ、テストを追加し、同じ失敗を防ぐ。しかし、まだ言葉になっていない問題は入力できない。人間が画面を見て、触って、立ち止まる必要がある。
AIと人間の役割は、作る側と使う側ではない
この開発を「AIがアプリを作り、人間が確認した」と説明すると、少し違う。
AIは実装者で、人間は発注者という単純な分担でもなかった。人間が違和感を見つけ、AIが原因を調べる。AIが修正し、人間が実機で確かめる。画面を見て別の問題に気づき、またAIへ戻す。
RELATED ARTICLE | AI / WORKFLOW
AIに記事を書かせる前に、AIが記事を書く環境を作った。
文章生成だけでは終わらない、AI編集環境の設計と制作基盤を振り返ります。
往復の途中で仕様そのものも変わった。最初は右ペインでよいと思っていた。実際に使うと無理があると分かった。タブへ変えた。さらに一覧画面から詳細を分離した。正解を先に持っていたわけではなく、動くものへ触れることで判断を更新した。
AIが作り、人間が採点するのではない。AIの出力が、人間に次の判断材料を渡す。その判断が、次のAIの仕事を作る。製品はその往復の中で少しずつ形になった。
最後に残ったのは、承認だった
AI Media Studioも同じ考え方で作っている。AIが動画を受け取り、素材を整理し、スクリーンショットを抽出し、Markdownを書く。人間はArticle、Images、Sourceを見比べ、修正するか、再生成するか、却下するか、承認するかを決める。
RELATED ARTICLE | AI / VIDEO
動画を放り込んだら、AI編集部はどこまで記事を作れるのか。
動画の投入から画像抽出、記事候補、レビューまでの実際の流れを追います。
最後まで自動化しなかったのは、承認だ。
それはAIを信用していないからではない。記事に必要なのが、文法的な正しさだけではないからだ。画像に過去の会話が写っていないか。説明の順番が不自然ではないか。読者へ見せる価値があるか。このサイトで出すべき記事なのか。
こうした判断には、事実確認と同時に感覚が混じる。感覚だから雑に扱ってよいのではなく、まだ仕様へ変換されていない重要な情報として扱う必要がある。
人間の仕事は、「これは違う」と言うことかもしれない
AIを使えば、人間の仕事がなくなるという話は分かりやすい。実際、コードを書く時間も、下書きを作る時間も減った。
ただ、減った作業の跡には判断が残った。何を作るか。どこが読みづらいか。何が不足しているか。どこまで自動化し、どこで止めるか。公開してよいか。
AI時代に人間へ残るのは、文章を手で書くことでも、コードを一行ずつ打つことでもないのかもしれない。
動いているものを見て、「これは違う」と判断すること。その違和感を言葉へ変え、次の仕事としてAIへ渡すこと。そして最後に、自分の名前で承認すること。
少なくともAI Media Studioは、その往復でできている。
