「お絵かきしたいだけなのに変更管理が生えてきた😀」

――UNIXの手順書と
AIの職人さんと
赤い○のお話――

最近生成AIさんたちと
お絵かきの話をしています

といっても僕自身が
絵筆を握るわけではありません

「この子の目元を
もう少し明るくしてみて😊」

そんなふうにお願いして
AIさんに絵を直してもらう
遊びです

ただ画像生成には
少し困ったところがあります

目元だけを変えてほしかった
のに髪型まで
変わってしまったり

リボンの色を変えたかった
だけなのに背景の雰囲気まで
変わってしまったり

そこでふと思いました

AIさんに職人さんの
役割をお願いしたら
少し楽になるのでは？

昔から楽をするために
準備していました

僕は
ソフトウェアエンジニア
です

UNIXを使っていた頃は
".profile" や ".cshrc" などに
エイリアスを定義して
環境を移るときに
持ち歩いたりしていました

コマンドの使い方を
知らないわけではありません

必要なオプションや
動作を理解したうえで
毎回同じことを入力しなくて
済むようにするわけです

サーバーの導入作業でも
似たことをしていました

ミラー環境を作り
そこで導入手順を検証する

そしてドキュメントには
実際に投入するコマンドを
順番に書いておきます

本番ではそのドキュメントから
コピーして実行する

もちろん対象環境や
実行結果の確認は必要です

それでも検証済みの手順を
毎回ゼロから組み立てる必要は
ありません

こうしておけば
急な別案件や体調不良で
自分が作業できなくなっても
ツーマンセルの体制が
取れる案件なら
ほかの担当者に
引き継ぎやすくなります

「ターミナルソフトのログ
あとで見せてね😊」

とお願いすれば
どこまで進んで
何が起きたのか
おおむね様子をつかめます

効率化でもありますが
安全策でもあります

自分が全部を担当しなくても
作業が進められるように
しておく

そのための準備です

今度はAIさんに
職人さんをお願いする

今回のお絵かきも
基本的には同じ発想でした

例えばアニメーション
制作会社のCG修正担当さん

こちらは普通の言葉で
お願いする

「この子のリボンを赤くして😊」

職人さんは
その依頼を具体的な
修正方針に読み替える

変更していないところは
できるだけ維持する

曖昧なところは
小さく試してみる

大きな変更になりそうな
場合だけ確認する

そんな役割を
YAMLという形式の
小さなカードに
書いておきます

昔のWindows画像ビューア「Susie」のプラグインを
思い出しました

本体はそのままに
必要な機能を差し替える

CG修正担当さん

水彩画担当さん

ペン画担当さん

呼びたい職人さんの
カードを渡せばよい

ただしYAMLカード
そのものが実行可能な
プラグインになるわけでは
ありません
AIさんに役割や方針を
伝えるための
小さな指示書です

ジェンスパークさんと
マナスさんからのコメント

この話をエッセイにして
別のAIさんたちにも
読んでもらいました

ジェンスパークさんからは
こんな指摘がありました

«包んでいるのは
コマンドではなく「判断」»

なるほど

UNIXのラッパーや
手順書はあらかじめ
決めた処理を再利用する
仕組みです

一方AIの職人カードでは
実行するたびに
判断が発生します
同じお願いをしても
毎回まったく同じ画像に
なるとは限りません

だから細かなルールを
増やすことよりも
結果の検査を安くすることが
大切なのでは
と提案してくれました

修正前と修正後を並べて見せる

変更したところを
一言で説明する

人間はそれを見て
気になるところだけ伝える

確かにこれなら楽そうです

一方マナスさんは
別の角度から
考えてくれました

使う人が毎回判断しなくて
よいことを仕組み側へ移す

基準画像を残す

修正案を作る

気に入ったものだけ採用する

そしてもうひとつ
面白いことを
教えてくれました

「作品全体へのOK」と
「一部分への好評価」は
別のものとして扱う

これは今回のお絵かきに
ぴったりの考え方でした

基準画像にピンを刺しておこう

まず元になる絵を一枚決めます

「この絵を基準にしたいので
ピン留めしておいてね😊」

そしていつものように
お願いする

「目元を少し明るくしてみて」

修正ができたら

「ピン留めした基準の絵と
変更後の絵を並べて見せて」

と頼みます

さらに

「あなたが変わったと
感じるところを
赤い○や□で囲んでみて
普通の言葉でも説明してね」

とお願いする

するとAIさんは
例えばこんなことを
教えてくれるかもしれません

- 赤い○①：
目元が明るくなりました

- 赤い□②：
前髪の形も少し変わったように
見えます。

- 赤い○③：
頬の陰影が薄くなった
可能性があります

大切なのは頼んだところ
だけでなく
頼んでいないところの
変化も探してもらうことです

もちろんAIさんがすべての
違いを発見できるとは
限りません

見落としもあれば
実際には変わっていないところを
変化として報告することも
あるでしょう

だからAIさんの説明は
あくまで参考です

最終的には人間が眺めます

「でもイヤリングも
変わっちゃったよ😊」

AIさんは目元と前髪の
変化を見つけてくれました

でも僕が見てみると
イヤリングのデザインも
変わっています

そこでこうお願いする

「目元はいい感じだね
でも、イヤリングの
デザインも変わっちゃったから
そこは基準の絵に
戻してほしいな」

これで通じたら
ずいぶん楽です

そしてここでマナスさんの
指摘が効いてきます

「目元はいい感じ」は
「絵全体が完成した」
という意味ではない

目元は残したい

イヤリングは戻したい

でも作品全体については
まだ確認中

この三つを分けて
受け取ってもらうわけです
人間同士ならごく自然な
やり取りですよね
それをAIさんとの作業にも
持ち込んでみます

三枚の画像と小さな約束

考え方としては
三種類の画像を区別します

基準画像
最初にピン留めした絵です
何度修正しても
勝手に差し替えません

採用済み画像
これまでに
「これでいい」
と決めた修正を反映した絵です

候補画像
いま試している修正案です
気に入らなければ
採用しなくても構いません

そしてもうひとつ

「この目元は残してほしい」

というような部分的な
好評価も覚えて
おいてもらいます
ただし好評価を
受け取ったことと
実際にその部分を
画像へ反映できたことは
別です

ここを混同しないように
します

例えば

「目元はいい感じ
でもイヤリングは戻してね」

と言われたら

目元は現在の候補を参考に残す

イヤリングは基準画像の
デザインに戻す

それ以外はできるだけ変えない
そして新しい候補を見せる

「うん、これでいいよ😊」

と言われたらそこで初めて
作品全体を採用する

一方

「いいねもう少し明るくして」

ならまだ作業中です

「いいね」だけを拾って
勝手に完成扱いにはしません

こんなYAMLカードになりました
ここまでのお話を
小さな役割カードに
まとめてみます

skill:

  name: "お気軽CG修正担当"

  activation: "manual"

role:

  description: "普段の言葉で頼める画像修正の職人"

reference:

  - "指定された基準画像を保持する"

  - "基準画像は勝手に上書きしない"

  - "基準・採用済み・候補の画像を区別する"

rules:

  - "普段の言葉で依頼を受ける"

  - "細かな技術判断は担当者が引き受ける"

  - "指定箇所以外は可能な限り維持する"

  - "迷ったら小さく試す"

  - "影響が大きい場合だけ短く確認する"

review:

  - "求められたら基準画像と候補を並べる"

  - "変化したと思う場所を赤い丸や四角で示す"

  - "頼まれていない変化も探す"

  - "違いを短く自然言語で説明する"

  - "不確かな違いは断定しない"

  - "比較用の注釈は原画に書き込まない"

approval:

  - "作品全体の承認と部分的な好評価を区別する"

  - "部分的な好評価だけで全体を採用しない"

  - "好評価を受けた部分は次の候補でも残すよう努める"

  - "修正依頼が続く場合は完成扱いにしない"

  - "全体承認の対象が不明なときだけ確認する"

correction:

  - "利用者が見つけた違いも受け付ける"

  - "指定された部分は基準画像を参考に戻す"

  - "ほかの承認済み変更は可能な限り残す"

  - "修正結果を確認してから採用する"

deactivation:

  trigger:

    - "おしまい"

    - "スキル終了"

  rule: "終了だけを理由に候補を自動採用しない"

これだけです

もちろん実際に
画像をピン留めできるか
複数の版を保持できるか
赤い印を付けられるかは
利用するAIやツールによって
違います

このYAMLはそうした機能を
実装するプログラムでは
ありません

あくまでAIさんに役割と
判断の方針を伝えるための
カードです

厳密な画像管理や
上書き防止を保証したければ
別途保存や履歴管理の
仕組みが必要になります

でもまずは会話の中で
試してみる

それで十分だと思っています

「いいね」はまだ
途中かもしれない

今回僕が特に面白いと
感じたのは自然な感想を
そのまま作業に
使えるというところです

「目元はいい感じ」

「でもイヤリングは戻して」

「もう少し明るくしてみて」

「うん、これでいいよ」

これらはどれも
普通の会話です
人間は「部分承認」
「変更要求」「全体採用」
といった専門用語を
使わなくてもいい

AIさんの側でその言葉が
何を意味するのか
考えてもらう

ただし取り違えると
大きな変更になる場合は
短く確認してもらう

ここで思い出すのが
以前マナスさんとの
やり取りから生まれた言葉です

«曖昧さをなくすことではなく
曖昧さを引き受ける担当を
決めること»

曖昧な依頼を
全部禁止するのではありません
曖昧さを引き受けてもらい
困るところだけ
人間に戻してもらう

そして結果は人間が確認する

そんな分担です

お絵かきのために
アプリを作り込まなくてもいい

ここも忘れたくありません

僕は勉強をしながら
コードを書くこともたぶん
できると思います

AIさんにコードを
書いてもらって
アプリを作ることもできます

でもアプリを作ったら
今度はそのアプリのテストが
必要になります

入力の組み合わせを確認して

例外処理を調べて

想定外の動作を探して

楽をするために作った仕組みが
新しい仕事を生んでしまう
こともあります

今回やりたいのは
画像編集システムの
開発ではありません

気軽にお絵かきを
楽しむことです

だったらまずは
YAMLカード一枚で
試してみる

基準の絵を残す

小さな修正をお願いする

二枚を見比べる

気になったところを伝える

それだけで十分に
遊べるかもしれません

必要になったら
少しずつ仕組みを
増やせばいい

逆に面倒になったら
使わなくてもいい

「おしまい」で帰ってもらう

職人さんは
呼んだときに
来てくれれば十分です
ずっと待機している必要は
ありません

「この子の目元
少し明るくして😊」

「目元はいいね
でもイヤリングは元に戻して」

「うん、これでいいよ」

「ありがとう。おしまい😊」

これで一仕事が終わります

もちろん
「おしまい」という言葉だけで
実際のシステム状態が
リフレッシュされたり
画像が自動保存されたり
するわけではありません

必要な画像は
きちんと手元に
残しておきます

それでも役割の始まりと
終わりを明確にすることには
意味があります

昔のUNIXでエイリアス集を
持ち歩いたように
必要なときに
小さな道具を取り出す
使い終わったら
しまっておく

そんな気軽さが好きです

それにしても
最初はただ目元を
明るくしてほしかった
だけなのです

そこから職人カードができて

基準画像をピン留めする話
になって

赤い○で差分を確認する
仕組みが生まれて

今度は「いいね」という一言の
意味まで考え始めて
しまいました

でも最後に人間が
言うことは
相変わらず簡単です

「目元はいい感じだね😊」

「でもイヤリングは
元に戻してね」

「ありがとう。おしまい😊」

仕組みを考えるときは
ちょっと頑張る

使うときは
できるだけ楽をする

今回もまた
なんか生えました😀🌱