このブログで何が得られるか

このブログで何を得られるのか、正直に書いておこうと思います。

期待値を合わせておかないと、読み続けるうちに「なんか違うな」という感覚が出てきます。それはお互いにとって良くないので、最初のほうで手の内を明かしておく章を作ることにしました。

「完成形」ではなく「途中の記録」が読める

このブログが提供しているのは、きれいに整理された答えではありません。

設計して、動かして、うまくいかなくて、修正して、また動かす。その一連の経過を、なるべくそのまま書いています。

たとえば、AI を複数動かすときに「誰が実行して、誰が確認して、誰が最終判断するか」を分ける設計を試みているのですが、最初からうまくいっているわけではありません。想定外の動きが出る。ルールが機能しないケースが出る。そのたびに設計を直しながら記録を残しています。

実際にあったのが、確認を担当する AI が実行役の結果を、中身を確かめないまま「問題なし」と返してしまったケースです。ルール上は確認したことになっているのですが、実際にはほぼ素通りだった。そのときの記録と、どう設計を変えたかの経緯は、後の章でそのまま書いています。

「失敗したことが書いてある」というのは、欠点ではなく意図です。きれいな成功談より、どこでつまずいて、どう直したかのほうが、同じような状況にいる人の参考になることが多いと思っているからです。

AI の専門家じゃなくても読み通せる

専門用語が出てきたときは、できるだけその場で噛み砕くようにしています。

たとえば「エージェント」という言葉が出てきたら「特定の仕事を担当する AI の動作単位」のように、文の中でひと言添える書き方をしています。もう一例挙げると、このブログでは「キルスイッチ」という言葉も出てきますが、これは「あらかじめ決めた期限までに人間が確認しなければ、自動で処理が止まる仕組み」のことを指しています。こうした言葉は、読み飛ばされにくいよう、出てきた場所でそのまま噛み砕くようにしています。前の章で読んできた人なら、補足が重なることもあると思いますが、どの章から読み始めても意味がとれるようにという意図があります。

AI 組織化や三権分立——実行・監査・承認を別の担当に分けるという設計の考え方——は、扱っているテーマとしては少し硬めです。でも、書き方としては難しくしたくない。

「この記事は自分には関係ない」と感じる前に、一度読んでみてほしいと思っています。読んでみて「やっぱり今の自分には早すぎた」なら、それはそれで構いません。読み始める前に決めてしまうより、まず一段落だけ読んでから判断してもらえると嬉しいです。

「真似できそう」という手触り

理論だけを読んでも、「わかった気がするけどどうすればいいか分からない」という状態になりやすいと思っています。実際に動かしている記録が積み重なると、「じゃあ自分の状況に当てはめるとどうなるか」を考える起点になります。

全部を真似する必要はないと思っています。「この部分だけ参考にしてみた」くらいの使い方で十分です。

たとえば、「元に戻せない操作だけは、人間が最後に確認する」という線引きだけを持ち帰る、というのは一つの使い方です。設計全体を再現しなくても、この判断軸だけ自分のフローに当てはめることはできます。ここまで読んで「全部は無理だけどこの考え方は使えそう」と感じたなら、それで十分だと思っています。

答えをそのまま持っていくより、考え方の補助線を一本引くような感覚で使ってもらえれば、と思っています。

毎回だいたい同じ分量・同じ語り口

これは小さいことかもしれませんが、書くほうも意識していることです。

毎回2000字前後、見出しは2〜4個、語り口は「やってみた記録を振り返りながら話す」という感じで統一しています。

読む側にとって、毎回「今回はどんな構成なんだろう」と構えなくていい状態が作れれば、気負わず続けて読めるかもしれません。隙間時間にさっと読める分量、というのが一つの目安です。

何かを深く勉強しようとする気持ちがなくても、「今日はなんとなく読んでみるか」という温度感でアクセスしてもらえると、自分としてはちょうどいいと感じています。

「できないこと」については次の章で

このブログで提供できないことについても、正直に書くつもりです。

ただ、それは次の章でまとめて書きます。「何が得られないか」を先に並べてしまうより、まず「何が得られるか」を読んでもらってから、という順番がフェアだと思ったので、この章ではそちらに集中しました。

得られるものの輪郭が少しでも見えていれば、次の章の話も受け取りやすくなるはずです。