📝

最大構成からミニマム構成へ——思考は、削ったときに立ち上がる

に公開
AI
ESP32
AI駆動開発
思考拡張
文脈
idea

最大構成からミニマム構成へ——思考は、削ったときに立ち上がる

AIに何かを頼むとき、よくこう言われる。

「プロンプトは短くした方がいい」
「要点だけを渡した方がいい」
「余計な情報は削った方がいい」

たしかに、それは間違っていない。

ただし、私は最近こう思うようになった。

ミニマム構成は、最初に目指すものではない。
最大構成を通過したあとに、削ることで発見されるものである。

この記事では、ESP32（マイコン）第2号機の接触不良から始まった小さな実験をきっかけに、AIとの文脈共有、記事構成、UI設計、そして設計未提示AI駆動開発へとつながる話を書いておく。

ESP32第2号機をミニマム構成で作ろうとした

FRB（Fishing Rod Benchmark）という、釣り竿の感度を振動として比較・可視化する個人研究をしている。

その中で、ESP32（マイコン）と加速度センサーを使った振動測定装置を作っている。

ある日、ESP32第2号機を作ろうと思った。

第1号機では、いろいろな機能や構成が増えていた。
そこで第2号機では、もっとシンプルにしたかった。

いわゆる、ミニマム構成である。

余計なものを削る。
必要最小限の部品だけで動かす。
そうすれば、構造がシンプルになり、原因も見えやすくなる。

そう思っていた。

ところが、うまく動かない。

マイクも付けていないのに画面側では反応が出る。
加速度センサーの接触も怪しい。
配線を触ると挙動が変わる。
再起動すると動くこともある。

最初は意味が分からなかった。

でも、しばらく触っているうちに見えてきた。

加速度センサー側の接触が一瞬崩れる。
センサーの電源または通信が落ちる。
ESP32側は動き続けているが、センサーを見失う。
ESP32を再起動すると、起動時の初期化で再認識する。

つまり、2号機は壊れていたのではない。

初期化タイミングと接触条件が揃ったときだけ、動いていた。

ミニマム構成とは、余計なものを削ることではなかった

ここで一つ、言葉が出てきた。

ミニマム構成とは、
余計なものを削る行為ではなく、
隠れていた依存条件を露出させる実験である。

今回の第2号機で見えたのは、単に「部品を減らせばよい」という話ではなかった。

むしろ、削ったことで見えたのは、

  • センサーの接触
  • 電源
  • GND
  • SDA/SCL
  • 固定方法
  • ケーブル角度
  • 起動時の初期化
  • 再起動で復帰する条件

といった、隠れていた依存条件だった。

第1号機では、いろいろな構成が積み重なっていた。
だから動いているように見えていた部分もある。

しかし、ミニマム構成に近づけると、支えていた条件が露出する。

削ったことで壊れたのではない。
削ったことで、支えていたものが見えた。

最大構成は、削るための母体である

ここで重要なのは、最初からミニマム構成を目指す必要はないということだ。

むしろ、最初は最大構成でいい。

最大構成とは、雑に全部盛りするという意味ではない。
可能性を広げるために、いったん多くの要素を含めるということである。

そして、そのあと削る。

削ることで、

  • 残るもの
  • 消えても成立するもの
  • 消すと壊れるもの
  • 消すと意味が変わるもの

が見えてくる。

だから私はこう考えるようになった。

最大構成は、ミニマム構成を発見するための母体である。

最初から最小構成を設計できるなら、それに越したことはない。

でも、まだ何が必要か分かっていない段階では、最初から削りすぎると、何が足りないのかすら分からなくなる。

最大構成を一度通過するからこそ、削ったときに差分が出る。

その差分が、思考を立ち上げる。

スマホWEBアプリも、最大構成から始まった

これはハードウェアだけの話ではない。

FRBでは、スマホの加速度センサーを使って振動を可視化するWEBアプリも作っている。

最初は、見せたいものが整理されていなかった。

とにかく入れられるものを入れた。

  • Time Series
  • Flux
  • Peak Timeline
  • 保存機能
  • 説明文
  • ログ出力
  • 各種グラフ

かなり情報量が多かった。

でも、その最大構成を見ながら、少しずつ削っていった。

すると、論点が立ち上がってきた。

スマホWEBアプリで本当に見せたいのは、精密測定ではない。
スマホでも振動に反応していることが分かる体験である。

Time Seriesは、生きている感じを見せる画面。
Fluxは、変化量を見る画面。
Peak Timelineは、周波数構造の雰囲気を見る画面。

最初からその整理ができていたわけではない。

最大構成を作り、削りながら、読者に見せたい画面が整理されていった。

つまり、ここでも同じことが起きていた。

削ることで、設計が立ち上がった。

記事ネタも、最初からミニマムで渡さなくていい

これは記事を書くときにも同じだ。

AIに記事ネタを渡すとき、最初から綺麗に短くまとめようとしなくていい。

むしろ、最初は冗長でいい。

背景。
経緯。
失敗。
違和感。
感情。
余談。
言葉になりきっていないメモ。

そういうものを、いったん最大構成で渡す。

すると、AIは勝手に整理する。
重要ではなさそうな部分を削る。
話の流れを作る。
見出しを立てる。

もちろん、AIが削りすぎることもある。

でも、そのときが面白い。

AIが削ったものを見て、

「いや、そこは消したらあかん」

と思うことがある。

その瞬間、自分が何を大事にしていたのかが見える。

AIが削った結果を見ることで、
自分が何を大事にしていたのかが分かる。

これは、文章術だけの話ではない。

AIが何を重要だと判断し、何を削ったのか。
そこに対して自分がどこで違和感を覚えたのか。

その削除差分を見ることで、自分の価値観や判断基準が露出することがある。

削除差分は、価値観の輪郭を浮かび上がらせる。

この視点は、AIと文章を書くときにかなり重要だと思っている。

AIに整理してもらう価値は、綺麗な文章が返ってくることだけではない。

AIが何を削ったかを見ることで、自分が本当に残したかった文脈に気づけることにある。

AIに渡す文脈は、最初から短くしなくていい

ここから、AIとの文脈共有の話につながる。

AIを使うとき、最初から短く、要点だけを渡そうとする人は多い。

もちろん、慣れている人ならそれでよい。

でも、初期段階では無理にミニマムを目指さなくていいと思っている。

なぜなら、まだ何が必要な文脈か分かっていないからだ。

最初から短くしすぎると、こうなる。

  • 背景が足りない
  • 制約が伝わらない
  • 判断基準が消える
  • なぜそれをやるのかが消える
  • AIの回答が一般論になる
  • そして「AIは使えない」と感じてしまう

でも、本当はAIが使えないのではない。

文脈の依存条件が渡っていないだけかもしれない。

だから最初は最大構成でいい。

背景も渡す。
経緯も渡す。
違和感も渡す。
失敗も渡す。
目的も渡す。
制約も渡す。

そこから削ればいい。

削る過程で、必要な文脈が見えてくる。

文脈のミニマム構成

この話は、いずれ「文脈のミニマム構成」という問いにつながっていく。

今はまだ、答えを出す段階ではない。

ただ、入り口だけは見えている。

削ったあとに会話が噛み合わなくなった場所には、
それまで見えていなかった文脈の依存条件が隠れていた。

たとえば、ある一行を消した瞬間に、AIの回答が急に一般論になる。

ある背景を消した瞬間に、会社向けの話ではなくなる。

ある違和感を消した瞬間に、記事の温度が消える。

ある制約を消した瞬間に、AIが全然違う方向へ進む。

そのとき、初めて気づく。

この一行は、ただの説明ではなかった。
この背景は、ただの余談ではなかった。
この制約は、思考を支える依存条件だった。

文脈のミニマム構成とは、おそらく、削っても会話が成立するものと、削ると噛み合わなくなるものの境界を探すことなのだと思う。

AIと文脈を共有する技術

私が今、手に入れたいのは「短いプロンプトを書く技術」ではない。

もっと根本的な、

AIと文脈を共有する技術

である。

AIと文脈を共有する技術とは、すべてを説明する技術ではない。

おそらくそれは、

  • 最大構成で文脈を渡す力
  • AIが何を拾ったかを見る力
  • 削除差分に違和感を覚える力
  • 消してはいけない一行を見つける力
  • 削っても成立する枝葉を見極める力
  • 次回も再利用できる形に整える力

の集合体だ。

そして最後の「再利用できる形に整える力」は、再現性につながる。

再現性は、信頼である。

一回だけ深い会話ができても、それは偶然かもしれない。
でも、似た深さの対話を別の場面でも再現できるなら、それは技術になる。

AIとの対話で本当に価値があるのは、一度だけ深い回答を得ることではない。

似た深さの対話を、別の場面でも再現できるようにすることだ。

その再現性が、AI協働における信頼になる。

設計未提示AI駆動開発へ

この考え方は、私が目指している「設計未提示AI駆動開発」にもつながる。

設計未提示AI駆動開発とは、最初から完璧な設計をAIに渡せない状態から始める開発である。

普通は、こう考える。

要件を整理する。
設計を書く。
AIに実装させる。

しかし、実際には最初から設計を書けないことがある。

何を作りたいのかはある。
でも、どういう画面が必要か分からない。
どんな操作がよいか分からない。
どの情報を見せるべきか分からない。

そんなとき、私はAIにこう頼むことがある。

「とりあえず、プロトタイプを作って」

これは一見、雑な依頼に見える。

でも、最大構成でプロトタイプが出てくると、そこから削れる。

この画面はいらない。
このグラフは残したい。
このボタンは邪魔。
この説明は必要。
この並びだと読者に伝わらない。

そうやって削っていくうちに、設計が見えてくる。

つまり、

設計を先に渡せなかったから失敗したのではない。
最大構成をAIに作らせ、それを削ることで、設計が発見された。

この発見プロセスそのものを、AI駆動開発に組み込めるのではないかと思っている。

思考拡張の3本柱としての「制約」

私は最近、思考拡張には3つの柱があると考えている。

  • 違和感
  • 体験
  • 制約

今回の話は、この中でも特に「制約」に接続される。

制約とは、思考を小さくするものではない。

一度、最大構成で体験を広げる。
そのあと、削るという制約を与える。
すると、何が必要だったのかが見え始める。

最大構成は、体験を広げるためにある。
ミニマム構成は、制約によって依存条件を露出させるためにある。
その削除差分に違和感を覚えたとき、思考が立ち上がる。

つまり、

最大構成からミニマム構成へ削る行為は、
制約によって違和感を発生させ、
体験の中から依存条件を露出させる方法である。

これが、今回のESP32第2号機から得た一番大きな気づきだった。

おわりに

AIに渡す文脈は、最初から短くしなくていい。

最初は最大構成でいい。

冗長でもいい。
整理されていなくてもいい。
違和感や失敗や余談が混ざっていてもいい。

重要なのは、そこから削っていくことだ。

削ることで、何が残るのかを見る。
削ることで、何が消えると壊れるのかを見る。
削ることで、自分が何を大事にしていたのかを見る。

ミニマム構成は、最初に目指すものではない。

最大構成を通過したあとに、削ることで発見されるものである。

そして、削ったあとに残った文脈を、次回も再利用できる形に整えられたとき、AIとの対話には再現性が生まれる。

再現性は、信頼である。

私は今、プロンプト術ではなく、AIと文脈を共有する技術を手に入れたい。

そのために、まずは最大構成から始める。

そして、削る。

思考は、削ったときに立ち上がる。

追記：ESP32第2号機くんへ

ありがとう、2号機。

君は測定器ではなく、概念発生装置だった。

なお、原因はたぶん接触不良である。

■関連記事

この思考拡張の実例として、私はFRB（Fishing Rod Benchmark）という個人研究を続けている。
釣り竿の感度を振動として比較・可視化しようとする、一見おかしな研究だが、そこで起きているのは「差分」「再現性」「制約」を使ったAI協働そのものである。

Discussion