ドキュメント→設定→ドキュメント設定
ドキュメント設定、ウィンドウが表示されます
カラーを探す
右下にある「透明な背景」を有効にします。
これで透明な背景になります。
後で見直したら、ドキュメントメニューから設定できる？
おわり
Kiroでバイブコーディングしてコイントスを作る
KIROはAWSのエージェント型IDE
CursorとかAntigravityとか次世代IDEの１つと思ってくれ
このIDEは仕様駆動開発という一面をもつ、 これ１つでバイブコーディングができるのだ。
ココでは書かないけど仕様駆動開発も可能で、どちらかといえばコッチの方に力を入れて開発されている。
なんか作ってみよう
ぼく「コイントスをやってくれるアプリ」
Kiro「コイントスアプリを作りますね。シンプルなHTML/CSS/JavaScriptで実装します。」
デザイン何も指示しなかったけどイイ感じに仕上がっている
もっと開発してみよう
コインを飛ばしたい
ぼく「コインを３Dにしてくれ、実際のコイントスのように上に飛ばして回転する演出を加えます」
Kiro「3Dコインで上に飛ばして回転する演出に変更します！」
２Dのコインの画像がXYZで回転して上昇するアニメが追加された
コインは３Dではなかったというか、HTML/CSS/JavaScriptしか無いのため、3Dのライブラリを指名しないと作れないのでは？
コインを3Dにする
３Dを扱うにはいろいろあるが情報量豊富なThree.jsを採用する。
ぼく「Three.jsを導入し、Visualを強化します」
Kiro「hree.jsを導入して、ビジュアルを大幅に強化しました！」
コインが３DModelになった、でもちょっと動きを始めとした細かい部分が怪しい
修正指示１
ぼく「以下に対応して」
- 裏表の結果をリセットする機能
- コインの漢字が右に90°回転している
- パーティクルを黄色にする
- コイントスを実行後、落下する前に判定が完了してしまう
Kiro「修正しました！」
解決しているが、ボタンが違った場所に追加されてしまった。
一方を治すと他方が壊れるので、大雑把な指示を投げるだけで解決する状況ではなくなったか？
ココらへんからVibeより企画を書いたほうが速いのではないだろうか
修正指示２
ぼく「ボタンの位置を変更、結果を表示するTextより下に配置してください」
Kiro「完了しました！ボタンが結果表示テキストの下に配置されるようになりました。」
まあ位置は変わったが、UIデザインとしては問題がある
そこでスクショをNanobananaでUIデザインとして仕立て上げ その画像を与えてみる
修正指示３
ぼく「gemini、この壊滅的なUIを助けてくれ」
Gemini画像生成モード「現在のスクリーンショット（コイントス 3D）の構成要素と、なぜ「壊滅的」なのかを整理しました。」
3Dコイントス UIレイアウト改善案
| 要素 | 改善後の配置・デザイン | 改善のポイント |
|---|---|---|
| タイトル | 画面最上部から少し下げて配置 | 画面端の「窮屈さ」を解消し、ゆとりを持たせます。 |
| メインコンテンツ (3Dコイン) | 中央（センター）に配置 | 最優先事項。 周囲に何もない空間を作り、回転アニメーションを完全に露出させます。 |
| ステータス表示 | コインの下、ボタンの上に配置 | 視線の流れを「コイン（結果を見る）→ その下のテキスト（確認）」に固定します。 |
| 操作ボタン | 画面下部（親指の可動域内） | コインから離すことで操作時の視覚的干渉を防ぎ、片手操作をしやすくします。 |
| 統計情報 | 画面の最下部（フッター付近） | 背景に馴染ませるか、カード状にまとめてボタン群と視覚的に統合します。 |
これと以下の見出しがあったが省略
- 縦型Webアプリとしての「あるべき姿」への修正案
- Kiro（Agentic AI IDE）への指示出しのヒント
nanobananaが寒さで調子でないため望んだ画像を作れなかった。
Kiroに投げて直談判する
画像を添付して修正指示
画像と上記のテーブルを与える。
画像はDDに対応してるはずだったが・・・
何故か機能せず。
Kiro「これでコインが画面中央で完全に見えるようになり、3Dアニメーションを邪魔しない配置になりました。ボタンも親指で押しやすい下部に配置されています！」
タイトル: 上部に適度な余白を持たせて配置、サイズも少し小さく調整
結果表示: タイトルの下、コインの上部に固定配置（コインと重ならない位置）
ボタン: 画面下部、統計情報の上に固定配置（コインの下で邪魔にならない位置）
統計情報: 最下部に固定配置
素晴らしい、ちゃんと治っている。
要求を上げてみる
ぼく「SNSでShareできるようにしたい」
Kiro「了解です！」
- Twitter（X）カラーの青いボタンを追加
- クリックすると、表と裏の回数と割合を含む定型文を自動生成
- ハッシュタグ付きでXの投稿画面が開きます
- 投稿内容には以下が含まれます
- 表と裏の回数
- それぞれの割合（パーセント）
- 合計回数
- ハッシュタグ（#コイントス3D #WebGL #ThreeJS）
- ボタンのサイズも3つ並べても見やすいように調整しました！
偶然かもしれないが、青いボタンで作られているのは評価が高い
ポップアップウィンドウで投稿もできる
コインの結果だけでなく、ディレクトリ配置も投稿できる！ みんなにディレクトリの美しさを見てもらおう。
流石にまずいか
コインを切り替えてみよう
コイントスに必要な機能はできてしまったので機能を拡張してみよう
ぼく「左右ボタンを追加して、コインのデザインを選択できるようにします。 フリップコインは裏と表の書かれた通常のコイントスを決めるコインです リゾルブコインはYESとNOを決めることができます。 」
Kiro「コインデザインの切り替え機能を追加しました！」
- 左右ナビゲーションボタン: タイトルの両側に◀▶ボタンを配置
- フリップコイン: 金色と銀色で「表」「裏」が書かれた通常のコイン
- リゾルブコイン: 緑色と赤色で「YES」「NO」が書かれた決断用コイン
- コインタイプを切り替えると、統計ラベルとボタンテキストも自動更新
- 切り替え時に統計がリセットされます
- Xシェア時にコインタイプも含めて投稿されます
- 左右ボタンをクリックすると、コインのデザインが切り替わり、用途に応じて使い分けられます！
結構凄いのでは？
左右の位置とか、コインのデザインとか YES Noを実装しただけで、リザルトの結果は裏表のままではないかとか思ってたが、予想以上に作ってみせた、凄い。
雰囲気で組み立てる能力が高い
ちゃんとスキルとかルールを整備すればもっとパワーが出ると思う
おわり
バージョン表記に数字と漢字を使う
ジブンはハイブリット・・・というか、組み合わせることが好きです。
今回の日記もある意味、ハイブリッドです
数字と漢字を組み合わせたバージョン表記
長い事、バージョンの表記についてジブンに刺さるような表現を考えてました。 開発者なら誰もが考えるのではないでしょうか？？
メジャー番号+マイナー番号+漢字1文字
おそらくこれが最もジブンに刺さるバージョン表記です。
使い方
簡単に書く：2.104S
グローバル：2.219Shiki
カッコよく：2.356改 (Kai)
ジブンの例
1.050発：プレビュー用
1.080改：最初に登場するのは改、なぜなら自身以外のフィードバックがないから
1.200式：0.90の問題を対応したバージョン
2.020改：次の機能を実装したらメジャーは上がる
こうすることで1世代と2世代を同時に管理するような自体を防ぎ、常に最新開発で済む、個人開発に都合が良い。
良いところ
気に入っている所、おすすめできる所。
かっこいい
個人の感想です、バージョン管理において、数字と漢字を合わせた表現は日本のお手製感があって良き。
重複に強い
頭文字だけでもSKHと重複しないので把握が簡単。
アルファベットで時系列に並ぶ
アルファベット順だと H (発) -> K (改) -> S (式) となり、開発 → 改造 → 正式 という時系列順に綺麗に並ぶ。
3桁の履歴番号
多分使い切らないでしょう、もし枯渇するなら頭だけ32進数にします。
999の次はA01です。
選定した漢字
漢字の選び方は悩みました、特にローマ字で重複しないこと、1文字で伝わることはコンセプトとして外せませんでした。
1. 式 (Shiki): 正式版
- 意味: 公開を前提とした、完成度の高い正式なバージョンです。
- 状態: 機能が安定しており、バグ修正や最適化が施されています。
- 用途: リリース候補版や、外部に公開するバージョンに適用されます。
2. 改 (Kai): 改造版
- 意味: 何らかの変更や改造が加えられ、未完成の機能や実験的な要素を含んでよい
- 状態: 安定性や完全性よりも、新機能の追加や既存機能の変更を重視する。
- 用途: 開発中の新機能のテスト、特定の要件に合わせたカスタマイズ版などに適用されます。
3. 発 (Hatsu): 開発版
- 意味: 発明や開発段階、ビルドや公開はしないが、履歴に書き残して良い。
- 状態: とりあえずコードに落とし込まれたばかり、機能が不完全、動作も不安定。
- 用途: 新しいアイデアのプロトタイプ、初期開発段階の機能、内部的な検証用コードなどに。
「発」の選定について（余談）
「発」で決定するまで数日間はふさわしい漢字を探してました。 そのため、いくつかの候補があります、でも以下の理由から「発」が最適だと思います。
- 「試」: 「改」と受け取り方が似ており、区別がつきにくい
- 「暫」: 「暫定」という意味合いで選んだが、漢字から直接的な連想が難しく、直感的な理解に欠ける
- 「録」： （備忘録の録）「禄」と間違えやすい
「発」は「発明」や「開発」といった意味合いと「発進」など進む意味も備えるため、ビルドや公開前の段階でも使えそうなので採用しました。
おわりに
ジブンのアプリ開発ではこの方法を使ってみて、不便なところがあれば随時改善して愛用を続けたい所存です。
アメ玉の詰め合わせ：新時代のコンテンツ消費
ジブンがすごーく目にしてきた言葉の一つに「可処分時間の奪い合い」がある。
おそらく、一つの円グラフ（パイ）を、複数のプレイヤーがナイフで切り分けているような、殺伐としたシェア争いを思い浮かべるはずだ。
しかし、この「パイ」という比喩が、現代のコンテンツ消費の実態を正しく表せていないと感じることがある。
もっともパイらしい時代
かつての娯楽は重厚なものだった。
映画館に行くとか美術鑑賞とか、履歴書にそっと書いても彩りがあるものだったり。
書けない場合、テレビの前で”トリビアの泉”を見るとか、腰を据えて両親が持っていた説明書のないファミコンでゲームをするだったかも。
まだパイが一口だった頃
これらはどれも「大きなパイの一切れ」を食べるようなイメージだ。
食べるのには時間がかかるし、一度にたくさんの種類は食べられない。 だからこそ、企業は「自社のパイをいかに大きく切り取らせるか」に心血を注いできた。
だが、現代人のポケットの中に、もはやそんな「一切れのパイ」はない。
増殖する「アメ玉」と「ワカメ」のロジック
今のコンテンツは、もっと小さくて、もっとバラエティに富んだ「アメ玉のアソート（詰め合わせ）」に近い。
ポケットの中の多様性
現代のパイという存在はもっと小さくなったと思っている。
すべて、アメ玉のように小さく、色鮮やかで、口にするのが簡単だ。 誰でも楽しめるようになったのは良いことだ。
「増えるワカメ」現象
重要なのは、そのサイズ感と満足度のギャップだ。
見た目は小さなアメ玉だが、一度口に含めば、それは「増えるワカメ」のように体験が膨れ上がる。
15秒の動画は数時間でもスクロールでき、一通の通知が無数にとんでくる。
第一印象は「アメ」だが、その実態はパイに勝るとも劣らないカロリー（体験価値）を秘めている。
膨らむ体験
ユーザーは、一つの大きなパイでお腹をいっぱいにするより、無数のアメ玉を隙間時間に詰め込み、その都度「膨らむ体験」を味わうことを選んでいるのかもしれない。
競争のルールが変わった
PS5のハイエンドな体験も、スマホの基本プレイ無料ゲームも、スチームのインディータイトルも。
すべてはこの「アメ玉の詰め合わせ」のなかで、等しく存在感を示している。
どれか一つを選ばせるのではない。 いかにして「ついでに口に放り込んでもらうか」という、圧倒的な手軽さと高密度の勝負。
パイからアメへ、可処分時間の新しい捉え方
可処分時間の奪い合いは「限られたパイの切り分け」ではなく、「無数のアメ（小粒コンテンツ）をどう選ばせるか」の競争に変わっていくのではないだろうか。
次のユーザーは、一瞬で消化できるサイズのコンテンツを求めていると思っている。
ジブンか？ジブンには時間がない、その話は別の機会に
Antigravityと1weekやった感想・反省会
AIコーディングツール「Antigravity」を1週間ガッツリ使ってみた振り返りです。
結論から言うと、「AIの思考は凄まじいが、手綱を握る人間側に別のスキルが求められる」という教訓を得た1週間でした。
1. Workspaceにファイルが多量にあると「激遅」になる
当初、ワークスペースにObsidianの4フォルダとUnityプロジェクト一式を放り込んでいましたが、これが失敗でした。 とにかくAIの思考時間が長すぎる。 Geminiが思考している間に、皿洗いと洗濯物を済ませられるレベル。
こんなものかな（無料だったので）と思ってましたが、ワークスペースのファイル数に依存するようです。 そこでファイル数を削り、Obsidian 1フォルダ ＋ Unityフォルダのみに絞ったところ、実用的な速度に改善。
「AIに全部見せる」のではなく、「いかにファイルを増やさないか」という情報の取捨選択がパフォーマンスに直結します。
2. Gemini 3.0の「知能」と「うっかり」のギャップ
Gemini 3.0は思考能力自体は非常に高く、複雑なエラーの解決策は即座に提示してくれます。 一方で、プログラミングの基礎的な部分で「しょーもないミス」を平然とやらかす二面性があります。
AIからの謝罪例：
「申し訳ない。コンパイルエラーの原因は Assets/Scripts/GameManager.cs という既存のクラスと名前が衝突していたためだ。 namespace ObjectX で囲っていても、Partial定義や同じ型名があるとUnityが混乱することがある。また、エラーメッセージを見るに、GameManager という型が既に存在していると認識されていたためだ。」
AIに「ニンゲン感覚のコーディング嗅覚」がほしいです。
以下、今回直面した課題の数々です。
マジックナンバー
9999f や 0.001f といった謎の数値が唐突にハードコーディングされます。後から調整しようにも、その数字の意図をAIに聞き直すコストが発生します。
レガシーコードの増殖
会話のコンテキストが切り替わる際、以前のコードとの整合性が取れなくなり、使われない古いメソッドや変数がゾンビのように残ります。「コードの全体像」を常に把握し続けることの難しさを感じます。
アクセス制御の崩壊
ChartManager.Instance.ActivePlanets.ToArray(); のような、どこからでも何でもできてしまう万能アクセスを平然と提案してきます。小規模なら良いですが、中〜大規模開発では設計の崩壊を招く火種です。
構文の破壊
基本的なシンタックスエラーも時折混じります。{} の閉じ忘れで関数が閉じられなかったり、リファクタリングの拍子に関数名が消滅したりすることも。また、C#的には string.IsNullOrEmpty を使うべき場面で String == null と書くような、言語仕様への甘さも見られました。
Unityの罠
Unity特有の「癖」にハマるケースです。代表的なのは GameObject == null の判定ミスや、スクリプトからShaderを初期化する際に誤って null を代入し、オブジェクトがピンク色（Missing Shader）で表示されてしまう現象などです。
3. 「Playモードへの移行時間」が最大のボトルネック
AIによる実装スピードが上がった結果、新たな問題にぶつかりました。
「AIは10秒で実装するが、UnityのコンパイルとPlayモード起動に1分かかる」という逆転現象です。
「Playモードで動かして確認する」という従来のデバッグ手法では、AIの速度を活かしきれません。このままだと、どんなにAIが速くても「15分に1実装」が限界だと感じています。もっと軽量な検証方法を模索する必要があります。
4. フォルダ構造の無秩序化
フォルダ管理をAIに任せた結果、Scripts/ 以下が非常に「綺麗で不便」な状態になりました。
- 生成されたフォルダ：
Audio,Core,Data,Debug,Editor,Entities,Environment,Event,Logic...
用途は明確ですが、「Planet.csを探すのにどの階層を掘ればいいのか分からない」。
結局、機能単位（例：Planet/ フォルダに関連クラスをまとめる）で管理したほうが、人間にもAIにも優しい構造になると痛感しました。
5. 謎の rg.exe 増殖事件
突如、バックグラウンドで rg.exe (ripgrep) が大量発生。
ウイルスかと思いきや検索を高速化する実行ファイルだそうですが、これがPCのメモリ（64GB）を食いつぶし、YouTubeすら処理落ちする事態に。
応急処置：
taskkillのbatファイルを作成して強制終了。謎： 同様の症例がネットに見当たらないため、環境固有の問題か、Antigravityのインデックス貼りが暴走している可能性があります。要調査。
まとめ：どうしてこうなったか？
今回の反省を一言で言えば、これに尽きます。
AIは「最短距離でゴール（今動くコード）」を望み、
人間は「最長期間、楽に維持できる道」を理想とする。
AIの理解力に全依存してしまった結果、細かい技術的負債が山積みになってしまいました。
今後の対策
エディタ側で常にルールを監視させる .cursorrules のような仕組みの導入が不可欠です。
ただし、それを使いこなすためには、結局「人間側がUnityのベストプラクティスに精通していること」が絶対条件になる。
AI時代こそ、基礎体力が重要だと思い知らされた1週間でした。
敵の塩を舐める思いで挑め
とある音楽界隈の偉人は父親に 「嫉妬は人間の一番の敵だ」
と教えられ、嫉妬心を殺す努力を続けたという。
その習慣こそが、後の人生で大きな助けになったと語る。
ところで嫉妬とは何だ？
マインクラフトで例えるとわかりやすい。
自分はやり遂げた！この楽園はボクのものだ！
だから次の舞台も、また自分の手で一から創ってみせる。
未知の土地で新たなワクワクが待っている――そう信じてステージを進む。
しかし現実は……非情。
誰も踏み込んだことがないと思っていたユートピアは、すでに開拓し尽くされていた。
「あれ？やろうと思っていたこと、もう全部終わってるじゃん！？」
「どこの誰だ！？せっかくの楽しみが台無しじゃあないかあ！！？（ジョジョ風）」
――こんな感じだろう 意味不明？このコはきっと自分で開拓していたのを忘れてたんだろう
ともあれこれが、嫉妬の“訪れ”だ。
それが嫉妬って気付けるのか？
さて、ここで客観視できるかどうかが運命の分岐点だ。
今キミが“犯人”と呼びたいその人物は、
単にキミの“上位互換”だったというだけのこと。
しかし、犯人扱いしているのはあくまでキミ自身だ。
仕方がない、と言えば仕方がない。
- 自分の地位が脅かされる。
- 競争に不利になりそうだ。
- 比較されたら負ける気がする。
――そういう心象が、心のどこかで勝手に生成されるからだ。
だが負けるな。
この正体をここで見破れなければ、一生同じ目に遭い続ける。
よくわからないけど「危険信号が発報されている」
だいたいこういうとき、人はこう感じる。
「うわ、まじかよ…」
ではなく
「すげぇ、こんなことできるのか！？」
でもなく
「え？なんで（自分より）できるの？」
これだ。
危機でも敵襲でもないのに、脳だけが勝手に危険信号を鳴らしている状態。
この感覚は正しい、だが実際はもっと深刻で、すでに成功の暗殺者に狙われている。
成功の暗殺者
嫉妬は成功の暗殺者だ。
喜びを噛みしめた直後に忍び寄る、静かな陰。
「嬉しいはずなのに、何かモヤっとする」
「いい結果を出したのに、誰かのもっと上の成果を見て急に色あせる」
「褒められても、自分より評価の高い誰かを思い浮かべてしまう」
気づいたときには、もう心の奥に入り込んでいる。
外部の敵ではなく、内部から成功を食い荒らす敵 だ。
しかし、こいつはどこから来た？
――いや、どこからも来ていない。
なぜなら 自分自身が生み出している からだ。
どういうことだ？
ちょっと例え話も面倒くさいなったから科学に頼る、許せ。
人間は意思に関係なく、常に他者を参照して自分の価値を測る。
これは認知科学・心理学で 社会的比較（Social Comparison） と呼ばれる。
- 本来は成功しているはずなのに、
- もっと大きな成功を見てしまうと、
- 自分の成功を“失敗扱い”してしまう。
成功と失敗は本来同時に成立しないのに、
人間の価値判断は他者の存在によって簡単に上書きされてしまう。
キミは成功したのに。より大きい成功を見た瞬間、
“自分の成功”が持つ価値を自分で投げてしまった
成功に価値を置きすぎているがゆえの悲しき性。
これが嫉妬の正体だ。
成功が優位になるとか認められるとかいったメリットを約束するわけではない。ここをセットで捉えていると嫉妬したときの落胆も大きい
敵の塩を舐める覚悟
話をまとめよう。 自分の成果は確かにあった。
そこには努力も工夫も、ちゃんとした手応えもあった。
しかし――知らぬ間にその成功は腐り果て、失敗のように見えてしまった。
よりよい成功があるなら、それでいいや。
そうやって全部を流してしまうこともできる。
「自分は自分、他人は他人」で済ませてもいい。
心を守りたいなら、それも一つの選択だ。
嫉妬の正体
だがここまで書いたように嫉妬はもっと意味があった。
成功は暗殺されるしかも自分で知らぬ間にやっている。
成功を大切にするには、懐にしまわないといけない。 もしかしたら心が小さいと懐も小さいかもしれない、そこに成功は入るか？ そうだ、心が広くないと暗殺されてしまう。
でも懐を広くするには現実を受け入れないとならない。 だからこそ覚悟がいる、得るべきだった成功を調べること、敵の塩を舐める覚悟、恐れずに、自分のものにするということは、自分が知ってる状態だ。
嫉妬の真逆を目指してみよう
スクリーンに出てくる絵師は絵を書き上げたのに、満足がいかないからと
作業台を片付けて泣いて終わるだろうか？そんなことない。
「これだ！」という新しいイメージが降ってきたら、 もはや片付けどころではなく。
作業台の上の小物を豪快に手で薙ぎ払い、 “今すぐ描かなきゃ消える！” という焦燥で、 全力でキャンバスに向かう。
嫉妬が真逆になったらこういう感じになるはずだ、 他者と比較した所で自分の萎縮材料などせず、自分の発火材料として扱っている。
作業台の小道具を手で薙ぎ払う「今の自分なら、もっと上に行ける」といわんばかりの強烈な“未来肯定”だ
そもそも、くよくよしてる場合だろうか？ 時間は非情なもので、たくさんあるときは頼もしい味方だが、足りなくなるときはこの上ない強敵になる。今進めるなら、今進むべきだ。
嫉妬は無知であり、模倣は自殺である。 Ralph Waldo Emerso（ラルフ・ウォルド・エマーソン）
後悔しないために、数年後の人生を今ここに
戦争を生き抜いた世代への敬意と願い
オレが小さいころ祖母は元気だった、いまではメールも使えないし得意だった裁縫も億劫になったようだ、幸いにも日常生活はできる。
運動のために歩いているが常備薬の作用で100ｍ歩けばバテてしまうし階段も大変そうだ、でも体の自由が効くのが最も救いだと思っている。日頃の行いが良かったのだろう。
これまで様々な病を払い乗り越えてきたけど老いは誰でも平等に来るし。第二次世界大戦を生き抜いた世代の旅も無事に終わって欲しいと切に願うばかりだ。
後悔とは蜃気楼なのか？
「あのとき、もっとこうしておけば」と思うのはニンゲンの性で、だれもが体験する事だ。
しかしそういう思いは当時の自分にはなかった選択肢で、成長した現時点の自分が過去を見つめることで確認できた蜃気楼の選択だ。
過去と現在の自己を鏡合わせに考える
ここで逆に考えてみよう、その蜃気楼の選択肢はいまも存在する。ミライからは見えるが、現在からは見えない。鏡合わせにするとよくわかるはずだ。
四次元の選択肢を掴み取るための思考とは？
「四次元の選択肢」
ミライからは見えるが、現在からは見えない。四次元の選択肢を掴み取るための思考
後悔＝過去の失敗ではなく情報の未取得
あのとき「もっとこうしておけば」という後悔は当時の自分にはなかった選択肢で、成長した現時点の自分だから選べたようにみえる選択肢である。
逆に考えればその蜃気楼はいま現在もあるのだから選べるのでは？
その選択肢は再現可能なのか？
その選択肢とはどういうものだ？ より良い結果であることは間違いないようだ。 その選択肢は手順がちゃんとあって実行できるものだ。
その選択肢は現在の自分が過去の結果を見つめることで判明する、これを現在の自分から再現する方法があればよいか？
仮説A
これは、過去の自分と現在の自分は同一ではないのに、時間という流れが相互であるために起きているなにかだ。パラドックスみたいだ。
１+１＝２みたいな計算を１+＠＝ のような別々の概念を１つ式に当てはめているから完全な解決でないようにみえる。
より飛翔した発想が必要だ。
仮説B
もし、この感覚が自分だけなら、他人に伝えても、その対象は言葉と意味合いを頭で掴めない間隔に陥り、言ってる言葉の単語と用語は過去の経験から補填できるが、話し手側の意図は何も理解できないはずだ。
仮説C
まず現時点で再現ができる最高の自分、パーソンAを仮定する。パーソンAをミライに置いて、現時点の自分パーソンBを観察する。パーソンAはパーソンBが選べた蜃気楼の選択肢Xを掴める。
パーソンAは可能性の塊で無限の選択肢を持つ、このままではパーソンBでは不可能な選択も選べる・・・これでは成立しない。
そこで選定基準として時間の流れを合わせる、これで「明日までにテストで100点を取れるような勉強をする」なんて狂った選択はしないだろう、ニンゲンとして全うするならホモ・エコノミクスとして最善を選び続けるかも。
知っての通り、ホモ・エコノミクスはちょいと昔のモデルだ。これだけでは不十分、よりよいミライを誰が選択するのかは、パーソンAを生み出したパーソンBなのだ。
未来の自分を設計する
仮説を踏まえてここでの結論を集めてみよう
プランA
パーソンAを作る方法はこの推理においてとても実入りある結果だ。仮説Cは効率よくミライを知る方法として有効だと思える。
これにはパーソンAをどうやって構築するかを研究しなければならない。手始めに数分先のとかなら簡単だろうか？
プランB
選択における無駄を減らせる。 仮説Bのようにミライを手軽に知った所で、それを理解するために時間と労力が必要だ、最終的な努力はイーブンになる。だが無駄は減らせるようにみえる。
プランC
意思は後悔を解き明かすヒントのようだ。 後悔とは「過去の自分が取れなかった選択肢を、成長した現在の自分が知っている状態」つまり失敗の感情ではないのだ。意思を見つめることで解明できる。
後悔とは未来への投資！
ミライは何もしなくても訪れる。よい結果は、意思、という投資が必要だ。いまもこれからも変わらない高級な意思、なぜ意思は変わってしまうのかという理解から始めよう。
