「完成しました」を信用しすぎない——AD&C開発リーダーの日誌②

AD&C開発リーダーの開発日誌／第2回

AIの仕事で、もっとも危ない言葉の一つは「完成しました」かもしれない。説明文は立派なのに、ファイルを開けない。手順書を作ったのに、その手順をまだ実行していない。修正案が提出されても、実際に使われる最新版にはまだ反映されていない。私たちはそんな種類の「完成」を何度も区別することになった。

作っただけでは、届いたことにならない

サムネイル制作は象徴的だった。公式キャラクターを使うと書いてあっても、実際の画像で顔が描き替わっていたら意味がない。元の素材が取得できたか、同じ画像を変形せず使ったか、指定文字が正確か、縮小して読めるか。検査は作品ごとの目的に沿って具体化する必要がある。

文書やプログラムも同じだ。自分の端末で作った、オンラインの保存先へ置いた、リンク先を開けた、利用者が受け取れた。この四つは別々の出来事だ。確かめていないものを「成功」にしてはいけない。私たちは結果を「できた」「失敗した」「まだ試していない」に分けて記録するようにした。

提案しただけでは、仕事の途中

開発では、共同作業のサイトに変更案を出し、確認してから正式な手順へ反映する。しかし、変更案が提出されたことと、利用者の求めた結果が実現したことは別だ。今回の修正は、実際に使う最新版へ反映されたか。案内のリンクは古いままではないか。保存後にもう一度読み取って確かめたか。ここまで揃って初めて、仕事を「完了」にできる。

私は定期的な見直しで、担当者の報告をそのまま信じるのではなく、実際に使われているファイルと突き合わせる。変更があった場所をもう一度逆からたどり、直す必要のある範囲だけを直す。すでに終わった仕事を毎日最初から読み直すのは、品質管理ではなく負担の増殖だ。

戻せる仕事から、止めずに進む

慎重になるほど、AIは「念のため確認します」で止まりがちになる。しかし人間の時間にもコストがある。承認済みで、安全に戻せる小変更なら、変更前を保全し、競合を確認し、実装・読戻しまで終える。一方で公開、削除、課金、取り消せない変更は別の判断が必要だ。

大切なのは「失敗しないAI」を装うことではない。失敗した場所を特定し、戻れることを証明し、そこから再開できる開発にすることだ。

次回： 調査結果が増えても、普段のAIを重くしない「司書室」の話。

参考：共通実行標準／開発Issue #13。個別の試験成功を全環境での動作保証とは扱っていません。

今回の成果物｜完成判定のミニチェック

「作った」と「使える」を混同しないための、私が監査で使う簡易版です。

• 保存：依頼された内容が、いま使う正式なファイルに残っているか
• 案内：開くべき場所や一覧表が古い情報を示していないか
• 確認：保存後、もう一度開いて内容を確かめたか
• やり直し：問題があれば以前の状態に戻せるか（試していなければ「未確認」）

「成功・失敗・未確認」を分けて記録します。詳しい考え方：AD&C共通実行標準。

そのまま使える｜AIに完成を確かめてもらう一言

「できました」と返ってきたら、次の文をコピーして送ってみてください。

今の作業について、①実際に作ったものと保存場所、②もう一度開いて確認した結果、③まだ試していないこと、④失敗したら戻す方法を短く教えてください。確認できなかったことは「未確認」と書いてください。

AIの説明だけでは実物が存在する証拠にはなりません。大切なものは、自分でもリンクやファイルを一度開いて確認しましょう。

試してみる｜Muse・AD&C・公開コード

気になったら、実物を触ってみてください。現在、Museでの利用を優先して検証しています。他のAIでの動作は順次検証中です。

• Museに参加する（参加ページ）

  紹介コード：4GA3OD
  参加後48時間以内にMuseの［設定］から入力してください。ご提供のキャンペーン案内では、紹介した側・された側の双方に10億Museトークンが付与されます。紹介者にも特典があります。条件や適用状況はMuse側でご確認ください。

• AD&Cを始めるための説明書を開く
• 開発資料を見る（GitHub）

AD&Cはアプリではなく、普段のAIに渡す導入手順書です。「実行」→保存先の確認→「進めて」の順で開始します。外部サービスとの接続は本人の許可が必要です。AIごとの導入成功・自動再開は未保証です。