Hiroto Aibara

東大ボート部 ▶︎ プラズマ物理学研究（大学院）▶︎ 株式会社Speee ▶︎ ブーストコンサルティングのエンジニア
「知恵フクロウ」と「ビルド・ブースケ」の生みの親

[Hiroto Aibara @aibara_hiroto]

https://t.co/EPp6qdA1G3

[Hiroto Aibara @aibara_hiroto]

AI駆動開発により増幅される6つの問題。
逆に言えば、これらの問題を仕組みで防ぐことができればAI駆動開発は真のポテンシャルを発揮し、その速度は光速を超え、明日始めるはずの開発が昨日終わる。

1. ユーザーの意図と開発側の認識がずれる

ユーザーの言葉、開発者の理解、AIへ与えられた指示が一致するとは限らない。暗黙の前提や判断が共有されないまま実装が進むと、動くものができても期待とは異なる結果になる。フィードバックを得ても、その内容が要求や仕様へ反映されなければ、後続の開発は古い認識を基に続いてしまう。

2. 要求・仕様・実装・テストの整合性が崩れる

反復のたびに一部だけが更新されると、次の不整合が生じる。

・同じ種類の情報の中での不整合： 要求同士、仕様同士、実装同士、テスト同士が矛盾する。
・異なる種類の情報の間での不整合： 要求、仕様、実装、テストが互いに対応しない。
・更新時点の不整合： 新旧の情報が混在し、文書やテストが現状と合わなくなる。

その結果、AIと開発者は何を正として参照すべきか判断できなくなる。

3. 複雑性と、将来の変更を難しくする問題が高速に蓄積する

目の前の変更を最短で実現する実装を積み重ねると、本来は分離すべき機能同士の結び付き、小さな例外対応、重複実装、使われていないコード、必要以上に複雑な共通化、役割分担の曖昧化が生じる。変更の影響が関係する機能だけに収まらなくなり、反復するほど影響調査と修正に時間がかかるようになる。

4. 開発の方向性と段階的なゴールが曖昧になる

すぐに動くものを作れるからこそ、何を優先し、何を作らないかを明確にする必要がある。開発全体の方向性に加え、各段階で扱う範囲、期限、完了条件、確認したい仮説が曖昧なままでは、フィードバックを得る前に開発範囲が広がり、反復の区切りを失う。

5. 意思決定の根拠が失われ、安全に変更できなくなる

要求や仕様だけが残っていても、なぜその形になったのか、どの選択肢を退けたのか、恒久的なルールか暫定対応かが分からなければ、安全に変更できない。過去の制約を必要以上に守り続けたり、必要な制約を知らずに壊したりして、同じ調査と議論を繰り返すことになる。

6. セキュリティ・運用などの非機能要件が抜け落ちる

[Hiroto Aibara @aibara_hiroto]

オフィスに突如として現れた「Hard Things」の群れ。この本の序文を書く小澤さんによる寄贈。

そしてその序文は「吐き気と悪寒。」という衝撃的な書き出し。
印象的な文章の書き出しは、と聞かれたらパッと思いつくのは「親譲りの無鉄砲で小供の時から損ばかりしている。」と「吐き気と悪寒。」
誇張と忖度抜きで。

そしてこの本の中に出てくる、
「スタートアップで一番いいことはなんだか知っているかい？」
「2種類の感情しか経験しないこと。歓喜と恐怖さ。しかも、寝不足がその両方を促進するんだ。」
というマーク・アンドリーセンの名台詞もべらぼうに好きである。

そういう意味で言うと、今の私には「歓喜」「恐怖」「寝不足」のいずれも足りていない。

私は自分で購入したものが家にあるので遠慮したが、明日も残っていれば二冊目を貰おうかしら。残っていないだろうけど。

（写真は小澤さん撮影のものを借用）

[Hiroto Aibara @aibara_hiroto]

システム開発の民主化という文脈では、かつてはノーコード・ローコードという方向性が主流だったと理解しているが、これは言うなれば「作ることの民主化」。

一方で、今必要だと考えているのは「開発プロセス管理の民主化」。
なぜなら、AIの進化により、作ること自体は別の方向から民主化が実現され、ボトルネックが別の場所に移動しているから。

[Hiroto Aibara @aibara_hiroto]

今週の最大の学びは、大きな問題は解決可能なサイズに分解し、その要素ごとに一つずつ確実な解決を図るべし、ということ。

何周目だよという話ではあるが、理解していることと常にやれることの差が大いに出やすいテーマだと痛感。これが凡事徹底ということだろうか。

ちなみにこのテーマの原典の一つと言えるのがデカルトの方法序説。
Gemini曰く、これが「近代科学の爆発的な発展を支える基本OSとなりました。」とのこと。
実務的な効用は基本的にない（完全個人的見解）が、興味がある方は是非読んでみられたし。
https://t.co/U6vbQXucUW

[Hiroto Aibara @aibara_hiroto]

1週間に一度くらいは見返そうと思う動画。

一度だけ大きなビジョンを打ち上げることができる人は沢山いると思うが、ビジョンが大きいほどTodoまで分解するのが難しく、またTodoに分解したとしてもビジョンを実現するまでの道のりが長すぎて、いつの間にか足元のTodoに引き戻されてしまう人が大半なのではないだろうか。

では孫さんとその他大勢の違いは何なのだろうか、「執着心」の強さだろうか。

執着心以外にも大きなビジョンを今日からのTodoまで分解しきる「分解力」みたいなものも重要そうな気がするが、それは執着心に比べたら些細なものだろうか。
https://t.co/BRYNFbJdgN

[Hiroto Aibara @aibara_hiroto]

大企業のシステム開発においては、まだまだ大手SIerが従来手法で開発するケースが主流ですが、いずれはAI駆動開発に置き換えられていく可能性は極めて高いと考えられます。

仮に、AI駆動開発の直接的な最大メリットは「早くて安いこと」だとすると、その帰結として得られるのは、変化への対応スピードではないでしょうか。
従って、発注側に立つ大企業においても、AI駆動開発を活用するケイパビリティを早期に獲得し、競争力を拡大していくために、何をどう変えていくか、という問いに向き合うことが重要です。

仮に外注という選択肢を取るなら、そのパートナー選定において重要な観点は下記のようなイメージではないでしょうか。

・AIの進化及び、その結果として生み出される変化へのキャッチアップが早いこと
・早く作れるからといって何でも作るのではなく、ビジネス視点での目的設定とそこに接続した開発ができること
・セキュリティ、パフォーマンス、保守性など従来通りの守りの観点も持っていること

必然的に、AI駆動開発ができることを武器としたい側にとって目指すべき姿もそこに重なります。

[Hiroto Aibara @aibara_hiroto]

https://t.co/9bLAnp0sDb

[Hiroto Aibara @aibara_hiroto]

このアプローチの要点は、「振る舞いの決定性」と「実装の自由度」を分離するということです。

旧コード→テストシナリオの変換は決定的に行う。ここで新システムが満たすべき振る舞いを固定する。

一方、その後のコード生成は確率的なAIに任せてよい。

生成結果が毎回異なっても、テストシナリオを満たす限り、要求される振る舞いは変わらない。

つまり、
「振る舞いは決定的に固定し、実装は確率的に自由にする」
という分離です。

ドキュメントリバースとストレートコンバージョンの間に、こういう第三の選択肢があり得るのではないか。ということを考えていたら電車を乗り過ごしました。（終）

[Hiroto Aibara @aibara_hiroto]

【AI スロップについての考察】
AIとの対話において、こちらの質問・依頼に直接的に回答せず、最後まで読んでも結局結論が分からない長文を投げつけられる現象に、誰もが悩まされているのではないでしょうか。

これに対するシンプルな解決策は、「こちらの質問・依頼に対して、直接的かつ端的に回答せよ」と指示することですが、これもしばしば悪手になりうるのが難しいところです。

なぜ悪手になりうるかというと、AIのツールとしての強みは、こちらの質問・依頼の前提に関する、矛盾や観点の欠落を都度補うことを容易にしてくれる、という点にあり、直接的な回答を強要しすぎることはこの強みを消す行為となりうるからです。
（電車を乗り過ごさないために以下略）

[Hiroto Aibara @aibara_hiroto]

過去のツイートを知らない人は「電車に乗り過ごさないために」で、ただただ困惑するであろう

https://t.co/HiRby6kx1E

[Hiroto Aibara @aibara_hiroto]

AIを使う際に重要なのは、AIをタスク実行のためのツールであると同時に、自分のストックとしての能力引き上げのツールであると捉えること。

AIを使って未知のテーマにチャレンジする際は、チャレンジをやり切るだけでなく、その過程を通じて、既存のベストプラクティスや、なぜこれで上手くいくのか、AIに聞き倒して、キャッチアップし倒す。

そうすれば能力が積み上がった分だけ、次はもっとチャレンジングなことができるようになるし、より大きな学びを得られます。
これを繰り返していけばとんでもなく遠いところまで行けるかもしれない。などと思いを馳せていたら、電車を乗り過ごし、家から遠ざかっていました。

[Hiroto Aibara @aibara_hiroto]

ふと、昔とあるブログにハマっていたことを思い出した。

私もこんな文章が書けたなら、
このアカウントもあっという間に万垢になり、
会社への採用希望者が殺到し、
クライアントからの問い合わせも殺到し、
全てが上手く回り出すようになるかもしれない

私もこんな文章が書けたなら

https://t.co/RsFxbLTYSI

[Hiroto Aibara @aibara_hiroto]

AIを使う際に重要なのは、AIをタスク実行のためのツールであると同時に、自分のストックとしての能力引き上げのツールであると捉えること。

AIを使って未知のテーマにチャレンジする際は、チャレンジをやり切るだけでなく、その過程を通じて、既存のベストプラクティスや、なぜこれで上手くいくのか、AIに聞き倒して、キャッチアップし倒す。

そうすれば能力が積み上がった分だけ、次はもっとチャレンジングなことができるようになるし、より大きな学びを得られます。
これを繰り返していけばとんでもなく遠いところまで行けるかもしれない。などと思いを馳せていたら、電車を乗り過ごし、家から遠ざかっていました。

[Hiroto Aibara @aibara_hiroto]

私は大学院で「自己組織化現象」に関わる研究をしていたのですが、自己組織化と「ハーネスエンジアリング」の間には明確なアナロジーがあります。

そもそも自己組織化現象とは、本来は拡散して無秩序になるはずの系が、自発的に安定した構造を形成する現象を指します。
例えば木星の縞模様も、気流によって形成された構造が安定して維持されている例です。

では、自己組織化と「ハーネスエンジニアリング」の間にあるアナロジーとは何か。それは、原理的に確率的であるLLMの出力に対して、上手くfeedforward や feedback の仕組みを外から与えることにより、意図した方向に再現性高くアウトプットを収束させることができる場合があるということ。これはもはやアナロジーというより自己組織化現象の一例とすら言えるのではないか。

何を言っているかわからないかもしれませんが、私も自分が何を言ってるか分からなくなってきました。

[Hiroto Aibara @aibara_hiroto]

私は最近松屋に通い詰めています。どれくらい通い詰めているかというと、松屋アプリの会員ランクが「プラチナ」を突き抜けて「ダイヤモンド」に達したほど。

さて、そんな松屋にはとある美食家をして「本質」と言わしめた逸品があります。その名も「ビビン丼」。
誕生から20年以上の歴史を持つ人気商品ですが、現状に満足することなく、去る8/27にはタレがさらに美味しくなってリニューアル。
前述の美食家にビビン丼の何が本質なのか尋ねた際の回答は、「とにかくバランスが至高」とのこと。界隈ではビビン丼が「本質丼」の別称で親しまれていることもそろそろ周知の事実かもしれない。

ここからが本題ですが、私が最近最も頻度高く食べているのは「本質丼」ではありません。
その名は「うまトマチーズ牛めし」。松屋オリジナルの牛めしの上にチーズとにんにくが効いたトマトソースが乗った背徳感たっぷりの逸品です。
「本質」の傍らにある「背徳感」を愛す、そんな生き方を一人でも多くの人に広めていきたい。そんなことを考えながら通勤していたら、職場を通り過ぎていました。

[Hiroto Aibara @aibara_hiroto]

このアプローチの要点は、「振る舞いの決定性」と「実装の自由度」を分離するということです。

旧コード→テストシナリオの変換は決定的に行う。ここで新システムが満たすべき振る舞いを固定する。

一方、その後のコード生成は確率的なAIに任せてよい。

生成結果が毎回異なっても、テストシナリオを満たす限り、要求される振る舞いは変わらない。

つまり、
「振る舞いは決定的に固定し、実装は確率的に自由にする」
という分離です。

ドキュメントリバースとストレートコンバージョンの間に、こういう第三の選択肢があり得るのではないか。ということを考えていたら電車を乗り過ごしました。（終）

[Hiroto Aibara @aibara_hiroto]

レガシーモダナイゼーションの方法論において、「ドキュメントリバース」から話が始まることが多い印象ですが、そこには明確な違和感があります。

ドキュメントはある種の目的では有用な一方、ソースコードをドキュメントにするということは必ず不可逆な情報圧縮が発生してしまうという事実からは目を背けることができません。

一方で、ルールベース変換によるストレートコンバージョンなら情報圧縮は避けられますが、保守性やパフォーマンスの観点で課題が生じやすいです。（続く）

[Hiroto Aibara @aibara_hiroto]

個人的には、ドキュメントの代わりに「テストシナリオ」を中間生成物とし、決定的な変換の向き先をソースコードではなく「テストシナリオ」とすることが、一つの解になるのではないかと考えています。

つまり、

旧コード
↓
決定的変換
↓
テストシナリオ
↓
AIによるコード生成
↓
全シナリオにPASSするまで反復
↓
新コード
という流れです。

どういうことかというと、（続く）

[小澤隆生（おざーん） @ozarnozarn]

ラクスルに2012年以来、14年ぶり2度目の投資を実施しました。取締役を務めるのも2度目です。
子どもの頃切磋琢磨した友人と、大人になって再び力を合わせるような不思議なご縁を感じています。企業も成長のステージが変われば、求められる役割も変わります。そんな新しいフェーズで、再びラクスルに関われることをとても幸せに思います。ラクスルのさらなる成長に、これまでの経験を惜しみなく注ぎ込み、全力で貢献していきます。
Let’s booooost together!

https://t.co/mhNU7XaDil