AIライティングアーカイブ

AIがコードを書き、テストを通し、ビルドまで終えた。

それなら完成しているはずだった。ところが実機で開くと、サムネイルは一枚も見えない。情報を追加した画面は横へ広がり、本文は細く押しつぶされている。直すためにタブへ分けたら、今度はウィンドウの中身が真っ白になった。

エラーは出ていない。テストも落ちていない。それでも、どう見てもおかしい。

AI Media Studioを作る過程で、何度もこの状況に出会った。そして最後まで残った人間の仕事は、コードを書くことより「これは違う」と感じることだった。

仕様を満たしているのに、使えなかった

AIへ依頼するとき、僕は要件を書く。Projects一覧へサムネイルを表示する。Project Detailにも同じ画像を出す。Review Queueでも共通利用する。画像は非同期で読み込み、存在しない場合はプレースホルダーを表示する。

要件としてはかなり具体的だ。AIは関連コードを探し、APIを追加し、SwiftUIへ画像ビューを組み込み、テストを書く。実装結果だけを読めば、仕事は終わっている。

しかし、実機のProjects画面には画像がなかった。左側には従来どおりプロジェクト名と状態が並び、右側にはMarkdown本文が表示されている。サムネイル用の領域そのものが見当たらない。

サムネイルが表示されていなかったAI Media StudioのReview Queue — 機能は実装済みのはずだったが、実機では一枚も表示されていなかった。

コード上の「ある」と、画面上の「見える」は別だった。APIが値を返すこと、Swiftのモデルが値を受け取ること、画像URLが認証を通ること、レイアウト内に表示領域が存在すること。その全部がつながって、ようやく一枚の画像になる。

正しさは、画面の気持ち悪さを検出しない

サムネイルが表示されるようになると、次は抽出したスクリーンショットを全部見たくなった。記事を書くための素材なのだから、代表画像一枚だけでは足りない。

最初は本文の上へ画像一覧を追加した。要求には合っている。ただし画面全体の高さが膨らみ、Markdownを読む場所が不安定になった。次に、右ペインへ情報を足した。今度は横幅が足りなくなった。

右側の本文領域が狭くなったAI Media StudioのProjects画面 — 情報を右へ足し続けた結果、本文が押しつぶされた。

機能は増えた。表示もされている。ボタンも押せる。それでも気持ち悪い。

この「気持ち悪い」は、テストケースに書きにくい。画面幅が何ピクセルなら失敗なのか。タイトルが何文字なら窮屈なのか。本文を読む人がどこで疲れるのか。数値へ変換できる部分はあるが、最初に問題を見つけるのは、たいてい視覚的な違和感だった。

タブに分けたら、何も表示されなくなった

横へ増やすのをやめ、Article、Images、Sourceの三つのタブへ分けることにした。記事を読むときはArticleだけを表示する。画像はImagesで独立してスクロールする。元動画の情報はSourceへ置く。

考え方は自然だった。実装も通った。ところが新しいアプリを起動すると、タイトルバーと青い選択線だけが残り、コンテンツは真っ白だった。

タブ化後に内容が真っ白になったAI Media Studio — クラッシュはしていない。ただ、使えるものも表示されていない。

ここでも「ビルド成功」はほとんど慰めにならなかった。TabViewの初期選択、NavigationSplitViewとの組み合わせ、ObservableObjectの初期化、画像読み込み、MainActor。原因候補を一つずつ外し、まずArticleだけを戻し、その後Images、Sourceを順番に復帰させた。

AIは候補を列挙し、コードを比較し、修正を作るのが速い。一方で、真っ白な画面を見て「前より悪い」と判断するのは人間だった。

人間は、答えより先に違和感を持つ

人間の判断は、いつも説明できる形で始まるわけではない。

「サムネイルが欲しい」と言う前には、文字列だけの一覧が分かりにくいという感覚があった。「画像を全部見たい」と言う前には、代表画像一枚では記事を書けないという不足感があった。「右へ出すのは無理がある」と言ったときも、最初から理想のレイアウトを説明できたわけではない。

まず違和感があり、その後で理由を言葉にする。AIへ修正を頼むのは、その次だ。

AIは明文化された問題に強い。ファイルを探し、影響範囲を調べ、テストを追加し、同じ失敗を防ぐ。しかし、まだ言葉になっていない問題は入力できない。人間が画面を見て、触って、立ち止まる必要がある。

サムネイルが並び、視覚的にプロジェクトを判別できるAI Media Studio — 違和感を言葉にした結果、文字だけだった一覧へ視覚的な手掛かりが加わった。

AIと人間の役割は、作る側と使う側ではない

この開発を「AIがアプリを作り、人間が確認した」と説明すると、少し違う。

AIは実装者で、人間は発注者という単純な分担でもなかった。人間が違和感を見つけ、AIが原因を調べる。AIが修正し、人間が実機で確かめる。画面を見て別の問題に気づき、またAIへ戻す。

往復の途中で仕様そのものも変わった。最初は右ペインでよいと思っていた。実際に使うと無理があると分かった。タブへ変えた。さらに一覧画面から詳細を分離した。正解を先に持っていたわけではなく、動くものへ触れることで判断を更新した。

AIが作り、人間が採点するのではない。AIの出力が、人間に次の判断材料を渡す。その判断が、次のAIの仕事を作る。製品はその往復の中で少しずつ形になった。

Article Images Sourceを切り替えられるAI Media Studioの記事画面 — AIが素材を整え、人間がArticle、Images、Sourceを見比べて次の判断をする。

最後に残ったのは、承認だった

AI Media Studioも同じ考え方で作っている。AIが動画を受け取り、素材を整理し、スクリーンショットを抽出し、Markdownを書く。人間はArticle、Images、Sourceを見比べ、修正するか、再生成するか、却下するか、承認するかを決める。

最後まで自動化しなかったのは、承認だ。

それはAIを信用していないからではない。記事に必要なのが、文法的な正しさだけではないからだ。画像に過去の会話が写っていないか。説明の順番が不自然ではないか。読者へ見せる価値があるか。このサイトで出すべき記事なのか。

こうした判断には、事実確認と同時に感覚が混じる。感覚だから雑に扱ってよいのではなく、まだ仕様へ変換されていない重要な情報として扱う必要がある。

AI Media Studioで記事をレビューしている画面 — 生成の最後に置いたのは公開ボタンではなく、人間が確認するためのレビュー画面だった。

人間の仕事は、「これは違う」と言うことかもしれない

AIを使えば、人間の仕事がなくなるという話は分かりやすい。実際、コードを書く時間も、下書きを作る時間も減った。

ただ、減った作業の跡には判断が残った。何を作るか。どこが読みづらいか。何が不足しているか。どこまで自動化し、どこで止めるか。公開してよいか。

AI時代に人間へ残るのは、文章を手で書くことでも、コードを一行ずつ打つことでもないのかもしれない。

動いているものを見て、「これは違う」と判断すること。その違和感を言葉へ変え、次の仕事としてAIへ渡すこと。そして最後に、自分の名前で承認すること。

少なくともAI Media Studioは、その往復でできている。

タグ: AIライティング

AIに記事を書かせたら、最後に残ったのは人間の違和感だった。