2026-07-31

よく見る個人とAIの関係と、複数人と、その先にありそうなの

AIの浸透度合いもまちまちかと思いますが、保守的な私の周囲でももう「使わない」がリスク扱いになってきた感じです。過去を思い返すとクラウドやコンテナあたりが同じような広がり方をしたかなぁという感覚です。他もあるかもしれないけれど、ぱっと思いつくのはそのあたり。 AIの使い方は色々ありますが、使い方の組み合わせはある程度パターン化できる感じがあるので垂れ流してみようかなと。

登場人物

人とAIと外界があります。

仕事をする中で、人は何かしら外界とやりとりします。

個人とAIのパターン

軍師型

外界とのやり取りは人間がやって、必要に応じてAIを活用します。 AIがいてもいなくても外界は関係ないです。

これは今までの仕事の延長線上で語れます。便利な道具を使っているのはこのパターン。特に問題はないでしょう。

外交官型

外界とのやり取りをAIが代行します。コミュニケーションの代理人。

問題解決とか行動の主体は人間で、あくまで外界とのやりとり部分を担っているパターンです。

具体例としてはアウトプットの体裁整えとかをAIに任せるもので、たとえばコミットメッセージやプルリクエストをAIが書いたまま送信しているもの。 AIの出力に目を通しているのは「軍師型」のほうになるので、現時点ではあまり多くはないように見えますが、例えばSNSのAI翻訳や要約だけでコミュニケーションしているのはこれの組み合わせっぽいなぁと思ったりしています。

司令塔型

いまのところはまだ多くないと思うけれど、今後ありえるなーと思っている、AIが人を使うパターンです。

外界と勝手にやり取りして、人間に何かしら働きかけてくるもの。「勝手に仕事をして、必要なときだけ声かけてくれたらいいのに」というすばらしいせかい。

実現可能性自体はもはや問題なく、あとはやるかどうかだけですかね。AIが勝手に受けてきた仕事もこなさないといけない。

黒幕型

軍師型と同様に外界とのやり取りは人間がやりますが、行動の主体はAIにあるものです。人間は伝書鳩や土管のようにAIの出力を外界に渡して、結果をそのままAIに伝えます。

あんちぱたーん。

個人とAIのまとめ

構造	AI	人間	人間の状態
`a ← A ⇄ 外界`	軍師	決裁者	AIの助言を受けながら、人間が判断し、相手と対話する。主体は人間にある
`A → a ⇄ 外界`	外交官	起案者	人間が意図や目的を持ち、AIに社会的な表現・調整を委ねる
`A ← a ⇄ 外界`	司令塔	担当者	AIが相手とのやり取りを進め、人間はAIから渡された仕事を遂行する
`a → A ⇄ 外界`	黒幕	傀儡	AIが内容や方向性を決め、人間はAIの意思を伝達する媒体になる

前述の見出しはAIのロール名でつけています。これに対応する人間のロール名を軸にする命名もできるので、その表。裏返し方も難しいものだけど、AIに候補を挙げてもらってニュアンスを足し引きしながらやって、こんな感じ。まだまだしっくりは来てないけど、個人の脳でひねり出すよりそれっぽい名前にはなっている気はする。100点ではないけど60点は取れてる、みたいな感じ。

パターンは組み合わせちゃいけない話なんてないので、現実では軍師＋外交官の使い方を意識してるのが多いんじゃないかなぁって。

2026年の現代は軍師型で使うのがメインでよしとされていると思う。とは言え場面を切り取ると黒幕型になっていることもままあるもので、私も油断するとなってたりなってなかったり。「なってていいんじゃね？」って思うこともしばしばなんだけど、その結果責任だけはAIに行かないんだよねぇと。

ここまでは「使い方に名前をつけて意識的に使うとうまく使えるようになる可能性があがるかもよ」という話です。名付けのぱわー。

複数人の話

個人とAIのパターンは「外界」の反対側で同様の組み合わせが存在します。ここからが書きたかったことなんだけど、余白が狭すぎる。（今年のテーマが「毎月ブログを書く」なので、7月中に投稿したいという意味。なお「時間があれば書く」とは言っていない。）

人間同士がやり取りしてお互い軍師型で使っていれば、これまでの延長線上で語れる。

片方（もしくは双方）が軍師型以外の使い方をしていたら延長線上では語れなくなります。

黒幕型同士だと傀儡同士で会話することになります。お互い「持ち帰って検討します」しか言わない人同士の会話に……あれ、これも昔からある延長線上で語れてしまう？と思ったけど、黒幕型の問題は自身が黒幕型と気づいていないときに最大化されるので、、、、（以下略

まとめ

AIを使わない選択肢がなくなっている昨今、相手の使い方のパターンを意識してみると多少やりやすくなるんじゃないかなぁ。という話でした。

蛇足だけど、「人間と人間のエージェントとしてのAI」という世界観では人間が必ずボトルネックになるんだけど、そこで詰まるかボトルネックを粉砕するかって話があり。粉砕する方向として、人間から離れた独立したAIがいる世界観。これも実現されつつあるなぁと思っている。

チームとしてはこの独立したAI（AIの先にAIがいるのは省略）をどう扱うのか。ちなみにAIの舵取りを人間がするのは「独立したAI」ではないです。「なにか」を通してAIに伝えるだけ。こっち方向の仮説を作るには情報が足りないので妄想しかできないなぁって。

参考

一般的な話に興味があるならhuman in the loopとかその辺のを読むといいんじゃないかな。ってClaudeが言ってました（伝書鳩）

2026-06-30

作って学ぶ Spring Boot入門

@suke_masa さんの書かれた「作って学ぶ Spring Boot入門」を頂きまして。

作って学ぶ　Spring Boot入門

作者:多田真敏
技術評論社

Amazon

AIだのなんだので激動の昨今ですが、新しくシステム開発業界に入られる方がいなくなるわけでもなく、「入門」は必要です。ある程度時間の流れに耐える入門書もあるにはあるのでしょうが、変化の激しいなかで「これ大方合ってるんだけどこの辺りは古いんだよね」のようなものは一部の入門者を大いに混乱させます。

情報を探せば検索エンジンをAIが使ってそれっぽいものを生成してはくれますが、初心者が自己学習に使用するには流石にまだまだ厳しい。そんな現代において、SpringBoot4.0、Java25というほとんど最新と言える条件で、一人の著者が書ききった入門書は代えがたいものなんじゃないかな、と思ったり。

さて内容の方はといいますと……

JavaやIDEのインストールからはじめ
ライブラリやJavaの軽いフォローをし
Springの話
DB、トランザクション
ブラウザでのUIとバリデーション
WEB API
認証認可

という感じになっています。気になる方は目次をご覧ください。

説明はそこそこにコード主体、作って動かしながら学ぶ感じ。写経しながら「ここ変えたらどうなるんだろう」と試すのが苦にならない方に向いている系の本です。

説明はそこそこと書きましたが、トランザクションのreadonlyやブラウザアプリケーションでのPRGパターンなど、単に「動かす」だけだと出てきづらいものの業務でやるなら知っておきたいところも触れていたりするのが面白いところ。

こういう構成図を使って「今動かしてるのここですよ」と示してくれるので、「動かしつつ構造で把握する」という学び方をする人は理解しやすいと思います。私はそのタイプなので、こういう図がない本だと自分で描いてたり。

図にある「単体テスト」とかその他諸々コンテキストによってまちまちな言葉も出てきますが、「この本ではこういう使い方をしている」というのは揃っているのが本の良いところだなと。

決して「一冊で即戦力に！」というような本ではありませんが、コードや図が多いので通し切るのにかかる時間はそこまでかからないと思います。スタートダッシュを一貫したコンテキストで走り切って、そこから着実に身に着けていく。そんな位置にある本でしょうか。

私の方はAI使って「せっかくだから」とあまり馴染みのない言語／フレームワークを使ったりしてるんだけど、出てくる実装や情報の一貫性のなさにあわあわしてる今日このごろ。これはこれで面白いんだけど、初心者の学び方ではねーやね、と。

2026-05-28

「検算」と「選択」

AIと開発者の付き合い方について現時点で思ってることのメモ。

AIのパワフルさは今更いうまでもない。そしてこの手の話には必ず「AIがあれば人間の開発者は不要」みたいな話がついてくる。ある面では正しいが、そういう主張をする人は自分の答えを持っている（これ自体は悪いことではない）し、面倒なのでそういう主張からは距離を置いている。

将来的に「現時点で開発者の仕事と思われているもの」の多くがなくなるのはそうだと思う。遠い将来ではなく、今この瞬間もなくなっている（本当に消滅したということではなく「なくなったと言って良い状態」になっていること）ことだろう。そういう仕事がなくなるとかいう方向の話は別でやるとして。

現時点での開発者（およびAIを使用する多くの仕事）の仕事はなんなのか。それを言葉にするなら「検算」と「選択」になるかなと言うのが本稿の趣旨。

AIに答えを求めるとそれっぽい答えが出てくる。この答えが妥当なのかを調べる必要があるのがAIを使っていくなかで必要なことで、「コンピューターは正確だが柔軟性がない」というひと昔前のイメージの真逆である。正確な振る舞いはコンピューターが得意とするところなので、「答えが合っているか」をコンピューターに調べさせるのは当然の活動。ハーネスとか言ってるのがこの辺なんだろかってふわっと思ってる。

検証を無邪気にAIに任せてるのがしばしば行われるが、これがイマイチなのは「正確でない答えを正確でない方法で検証しても正確でないまま」という単純な話になるので効果は限定的である。「正確でない人間の仕事を正確でない人間がチェックする」というのはダブルチェックなどで行われることであるが、限界があるのは知っての通り。

つまり、AIの仕事の結果を検証する方法は正確である必要がある。「正確な方法を使った検証」を実行するのはAIでよい。この辺りの構造を認識したり設計したりできるかがAIを使うものに必要なスキルである。が、そういう組み合わせとかもAIができるようになっている。

では人間がやるべき仕事ってないのでは？となるのだが、ここで「検算」と「選択」という言葉を用いる。

検算は別の方法で確かめること。その方法を選択するのが人間の仕事で、選ばれる方法は「（その答えに関わる）人間が扱えるもの」でなくてはいけない。関わる人間が理解不能なロジックでしか検算できないものは「検算不能」として捨てるのが、人間の仕事じゃないかなって。「検算」は「伝えたい相手に伝わる言葉での説明」である。伝えたい相手はステークホルダーと呼ばれる人かもしれないし、対象プロダクトをメンテしていく開発者かもしれない。

AIはしばしば人類には理解不能な答えを出してくる。それはひとめ「間違っている」と映ることもあるが、よくよく確かめると正しいこともなくはない。唯一無二の答えならそれを選ぶしかないが、多くの場合、答えは一つではない。ゆえにいくら正しくとも「選ばない選択」をするのが、人間の仕事じゃないかなって。

人間に合った答えを選び、人間が扱える方法を選んで検算する。人間に合っていない答えは選ばない、人間が扱えない方法での検算は採用しない。

って感じ。

昔からある構造

AI関連で色々と「今までとは違う！」って話はでるのだけど「構造は変わってないなぁ」と思うことはよくある。今回の話も技術差のある現場では昔からよくある話だったりする。

技術差があると技術上位者による「他のメンバーが理解できないが正しい答え」はしばしば持ち込まれるが、それをそのままにするとスケールしなかったり、オーパーツ化して痛い目にあったりする。そこで「メンバーのスキルをあげる」のと「メンバーがわかる（あるいは将来的にわかるようになる）レベルの答えを選択する」などの方法を組み合わせて対応してきた。AIでも同様のことが必要ってだけの話。

なので別に新しい考え方でもなんでもない。

のだけど、「メンバーがわかるようになる」は答えを出したのが「言うても同じコンテキストに同席した人間」条件下だったのである程度期待してもよかった（酷なこともあるが）。しかしながらAIとなると「人間にAIと同じレベルになれ」を要求するのは流石に無理がある領域もある。その辺は差分かもしれない。

プロの投手で160km/hのボールを投げられる人がいて。同じプロの投手でトレーニングにより投げられる人がいるのを期待するのは自然。でもピッチングマシーンが300km/hのボールを投げるからといって、人に投げられるようになるのを期待するのは違うよねって。