（わりと常々言っているログだけを収集したい的な話。これも生成した文章です。主張が弱まってしまって物事を全て平等のものとして扱ってしまってる感覚があります。いつも通りメイキングは後に繋げます。メイキングが本題みたいなところがあります）
🌱 はじめに：情報との向き合い方について思うこと
日々、X（旧Twitter）を開くと、膨大な量の情報が流れ込んできます。
その速度と量に圧倒されることも少なくありません。
活発な議論や新しい視点に触れられるのは刺激的ですが、一方で、時折、意見の応酬や強い主張のぶつかり合いに少し疲れてしまう自分もいます。
もっと地に足のついた、経験や事実に基づいた情報交換ができないものだろうか、と感じることがあります。
先日、私自身が「共有のコンテキスト」や「ログ」の価値について、いくつかのポストを連ねて投稿しました。
その一連の思考を整理する中で、改めてSNSにおける情報のあり方や、私たちがどのように情報と向き合っていくべきかについて、考えを巡らせました。
この文章は、その思考の過程を書き留めておく、個人的な備忘録のようなものです。
💬 現状認識：「意見」が優勢に見えるSNS空間
タイムラインを眺めていると、どうしても個人の強い「意見」や「断言」が目に入りやすいように感じます。
これは私の観測範囲だけかもしれませんが、客観的な事実の報告よりも、主観的な評価や主張の方が、より多くの反応を集めているような印象を受けることがあります。
また、興味深い現象として、発信者が単に事実を共有したつもりでも、受け取る側がそれを即座に「意見表明」として解釈してしまう、というケースも少なくないように思います。
例えば、「こういう方法を試したら、こういう結果になった」という報告が、「だからこの方法は良い/悪い」という意見として受け止められ、意図しない方向へ議論が進んでしまう。
このような「共有のコンテキスト」のすれ違いは、SNS空間では日常的に起こっているのかもしれません。
なぜ「意見」が目立ちやすいのでしょうか。
一つには、発信者側の動機として、自身の立場を明確にしたり、注目を集めたりするために（いわゆる「ブランディング」のために）、より断定的で強い表現を選びたくなる、という心理が働くのかもしれません。
そうした発言は、客観的な事実よりも、発信者の立場や意図を強調する「ポジショントーク」としての性格を帯びやすくなります。
さらに、他者の「良い意見」や「上手いこと言っている」とされる発言を引用したり、リツイートしたりする行為も、意見の流通を後押ししているように感じます。
それによって、自分自身も何か意味のある発信をしたような感覚を得やすいのかもしれません。
最近よく聞かれる「言語化」という言葉が、時に、こうした他者の意見の安易な借用を指して使われているように見えることには、少しだけ違和感を覚えることもあります。
📝 個人的に価値を感じる情報：「ログ」の重要性
こうした「意見」が飛び交う状況の中で、私が個人的により深い価値を感じるのは、意見そのものよりも、その根底にあるはずの客観的な事実や具体的な経験、試行錯誤の記録、すなわち「ログ」です。
私がスレッドで引用させていただいた @fromdusktildawn さんの「AIにこれやらせてもダメ」といった失敗談を共有しよう、という呼びかけには、まさにその点で強く共感しました。
華々しい成功事例ももちろん興味深いですが、それと同じくらい、あるいはそれ以上に、「何を試して、どういう理由でうまくいかなかったのか」という情報は、他者が同じ轍を踏むのを避け、より効率的に前進するための貴重な資源となるはずです。
誰かの意見が正しいか間違っているかを議論するよりも、実際に何が起こったのか、どのようなプロセスを経てその結果に至ったのか、という事実の記録＝「ログ」が、もっとアクセスしやすく、共有されるようになれば良いのに、と常々考えています。
それは、集合的な知見の蓄積に繋がり、より建設的な対話を生む土壌になるのではないかと思うのです。
🤔 「ログ」が流通しにくいと感じる理由
では、なぜ価値があるはずの「ログ」が、活発な「意見」の流通に比べて、あまり表に出てこないように感じられるのでしょうか。
私なりに考えてみると、いくつかの要因が思い当たります。
まず考えられるのは、SNSというプラットフォーム自体の特性です。
「ログ」は、その性質上、地味で淡々とした記述になることが多いでしょう。
感情的な反応を引き出しにくく、リツイートや「いいね」といった形で拡散していく「共有される力学」が働きにくいのかもしれません。
強い意見や驚きを伴う情報の方が、アルゴリズム的にも、人間の心理的にも、広まりやすい構造があるのではないでしょうか。
次に、発信する側の心理的な障壁も大きいと感じています。
特に「失敗」に関するログを共有する場合、単に「失敗した」と書くだけでは十分な情報にならず、どのような問題をどう解釈し、どのような方法を試したのか、といったプロセスを詳細に記述する必要があります。
しかし、その記述の中に自身の誤りや考慮不足が含まれていた場合、それが露呈することで、自身の専門性や評価が傷つくのではないか、という恐れ（私が「心理的恐怖」と表現したもの）を感じるのは、無理もないことかもしれません。
GoogleのE-E-A-T（経験、専門性、権威性、信頼性）という評価軸で考えれば、「経験」や「専門性」を示すためのログ共有が、同時に自身の「権威性」や「信頼性」を脅かすリスクをはらんでいる、と言えるのかもしれません。
一方で、「成功」したログの場合はどうでしょうか。
本当に価値のある、競争優位性に繋がるような成功のノウハウは、むしろ戦略的に秘匿される傾向があるように思います。
私たちが目にする華々しい「成功談」の中には、実際には、注目を集めるための先行アピールや、核心部分を伏せた「捨て札」的な情報である可能性も、考慮に入れておく必要があると感じています。
👀 情報とどう向き合うか：個人的な視点
こうした状況を認識した上で、私自身は日々流れてくる情報、特にSNS上の情報とどのように向き合おうとしているか、少し整理してみたいと思います。
まず心がけているのは、目にした情報が「意見」なのか「ログ（事実）」なのか、あるいは両者が混ざり合っているのかを、意識的に区別しようとすることです。
そして、発信者の意図――それは純粋な情報共有なのか、ブランディング目的なのか、ポジショントークなのか――についても、少し立ち止まって考えてみるようにしています。
情報の質を評価する上では、E-E-A-Tの観点、すなわち、その情報がどのような「経験」や「専門性」に基づいているのか、発信者に「権威性」はあるのか、そして何より「信頼性」はどの程度あるのか、といった点を意識することが有効だと感じています。
特に、「誰が言っているか」（権威性）という点に安易に引きずられず、その根拠となる事実やデータ、論理的な整合性があるかどうかを見極めたいと思っています。
また、価値ある情報源は、必ずしもその分野の「専門家」とされる人たちだけではない、という点も重要だと考えています。
時には、いわゆる非専門家（私が「驚き屋のアカウント」と呼んだような）からの、予期せぬ視点や率直な試行錯誤の「ログ」が、固定観念を打ち破るヒントを与えてくれることもあります。
ですから、専門家としての体系的な情報収集だけでなく、分野を問わずフラットな視点で情報に触れる「非専門家としての消費」の姿勢も、大切にしたいと思っています。
🚀 少し先の未来について思うこと（余談）
少し話が飛躍するかもしれませんが、AIをはじめとする技術の急速な進展が、これから情報の価値や「専門性」の意味合いをどのように変えていくのかについても、考えさせられます。
これは全くの余談ですが、思考の記録として書き留めておきます。
経済学に「比較優位」という概念がありますが、これまで人間（特に専門家）が比較優位を持っていた多くのタスクがAIによって自動化・代替されるようになった場合、特定のスキルや知識（専門性）そのものの価値は、相対的に低下していくのかもしれません。
そうなると、重要になるのはスキルそのものよりも、「どのAIが信頼できるか」「誰がその結果を保証するのか」といった「権威性」に移っていく可能性も考えられます。
もし仮に、その「権威性」が、個人の努力や実績によって獲得されるものではなく、例えば出自や所属、あるいは経済力といった、本人にはどうしようもない要因によって規定されるような社会になったとしたら…。
それは個人の可能性を狭め、格差を固定化する、あまり望ましくない未来（ディストピア）に繋がってしまうのではないか、という一抹の懸念も感じています。
もちろん、これは極端な想像かもしれませんが、技術の進歩が社会構造に与える影響については、楽観的な見通しだけでなく、こうした側面も含めて、継続的に考えていく必要があると感じています。
✨ おわりに：どのような情報空間を望むか
長々と書き連ねてきましたが、最後に、私自身がどのような情報空間を望んでいるのかを改めて記しておきたいと思います。
個人的には、やはり、多様な「ログ」――成功も失敗も含めた具体的な経験や事実の記録――が、もっと気軽に、そして建設的な形で共有される場であってほしい、と強く思います。
発信者が自身の評価が下がることを過度に恐れることなく、率直な記録をオープンにし、そこから他の多くの人々が学びを得て、それぞれの試行錯誤に活かせるような。
そのような情報空間は、誰か一人の力で作れるものではなく、プラットフォームの設計思想もさることながら、私たち利用者一人ひとりの情報との向き合い方、発信や受信の際の意識、そしてコミュニティ全体で育まれる文化によって、少しずつ形作られていくものなのだろうと考えています。
専門家であるか、非専門家であるかという垣根を越えて、事実に基づいた知見を尊重し、共有し合い、互いに学び合える関係性。
そんな情報との関わり方が、この複雑で変化の速い時代において、ますます重要になってくるのではないでしょうか。
この文章が、私自身の思考の整理であると同時に、もし同じような問題意識を持っている方がいらっしゃれば、その方にとって何かしらの考えるきっかけとなれば幸いです。
それもまた、ささやかながら一つの「共有」の形なのかもしれません。
メイキング
これはx/twitter上での自分の連投を下にした文章生成の試みの一つだった。
https://x.com/podhmo/status/1918911110683525409
実際にはこの話を経由して参照している
https://x.com/hirochuu8/status/1917508854734282804
AIでダメだったことは、意外とない。というのも何かがAIで達成できなかった時、自分の発想が足りない可能性が常にあるから。「現状のAIではダメ」と確定することがむずい。というか、そう断じることは浅はかだと思う
「AIでこんなすごいことが出来た！」
というツイートばかりがバズって、
「AIにこういうことやらせようとしたけどダメだった」
というツイートをろくに見かけない。
「AIにこれやらせてもダメ」というノウハウを知っていれば無駄足を踏まずに済むから、そういう情報をもっと共有しようぜ。
これへのコメントとしてこういうコメントをした。
できないと言わずに上手くいかなかったならいつ言っても良いと思ったりもした。
意見ではなく事実の列挙ならその時点のスナップショットに過ぎない上に備忘録的な価値がありそう。
後にこのコメントを参照して連投したスレッドが冒頭のものだった。
grokとの対話
文章の跳躍の存在を確認してもらったのが新しい試みだった。スレッドを跨いだ読解はしてくれないようだった。プロンプトは以下のような感じ。
explain this post and its replies https://x.com/podhmo/status/1918911110683525409 日本語で。文章の跳躍があったら指摘して。意味を推測した部分は括弧書きで明示して。
https://x.com/i/grok/share/iKaDfxVIVfAyBbRkNUtia8hL3
余談の追加とその筋の悪さ
余談という体のコンテキストの追加はあまり良くない感じがする。どうやら全体論と補助だとかちょっとした例外条件や補足という形のスレッドも各投稿を同等に扱ってしまってる。こういう余談の話が1つの章として同等の価値を持つものとして扱われてしまっている。
（これも余談。というわけで欲しいのはログであり知らなかったり詳しくない領域のニュース的なものが驚き屋のアカウントからも手に入る事がある。つまり専門家としての自分の情報収集ではなく非専門家としての消費の話）
（追記: この投稿が日本語として壊れた文章になってるせいもあるかもしれない。）
たぶんこのツイートと地続きの話だと思う。3つ目の話題（他は学習パスの再参照の話と内挿と外挿の話なので自明っぽい。）。
https://x.com/nishikazuhiko/status/1917575553022058658
１．質問の答えが決まった結論にいつも収束する
２．過去の分析はできるが、未来予測は苦手
３．過去の分析において、資料の評価に重みづけがない
文章の作成
文章の生成自体はai studioでの幾らかの対話の後に以下のようなプロンプトで生成した。
いいですね。いい感じです。それでは詳細を詰めて文章を作っていきましょう。章タイトルも付けてmarkdownの出力でテキストを作ってください。長くなっても構いません。丁寧に綴ってください。章タイトルにemojiをつけてください。太字の強調は一切使わないでください。
詳細を膨らませる場合にはます冒頭の対話ログを覗いてください。ない場合には学習した知識に頼ってください。
ちなみにpodhmo氏は私です。
これでもまだ学習した知識を参照してる感じはある。
うーん、どのような情報が溢れる社会が良いか？みたいな視点で集めた場合のパターンが欲しいですね。
あと自信満々な提言みたいなニュアンスはなくて良いです。私はこう考えるみたいな態度で十分です。こう考えるより思うのほうが近いでしょうか？（とは言え文章内容を変にわかりやすくする必要はありません。噛み砕く必要もありません）
あと元の文章や対話を受けての連想などの文章ではなくあくまで元の対話のまとめないしは備忘録的な意味合いの文章のほうが嬉しいです。
この部分などは勝手に挿入された文章。本番適用（？）の前には必ずこのような挿入は取り除いておきたい。
情報の質を評価する上では、E-E-A-Tの観点、すなわち、その情報がどのような「経験」や「専門性」に基づいているのか、発信者に「権威性」はあるのか、そして何より「信頼性」はどの程度あるのか、といった点を意識することが有効だと感じています。
E-E-A-Tを引き合いに出したがそれで適切に有用さを判断できるというような主張はしていない（学習器はそのように学習はしてると思う）。
元の主張自体の読解を聞く
最初に読み込ませた時にこのようなプロンプトを渡して整理したのは良かった。
お世辞のような余計な装飾は取り除いてください。
この文章の本題及び補助的な補足事項に分けて整理してください。本論は何ですか？いくつか可能性がある場合には複数挙げ自信度を併記してください。
ちなみに実際にはこれらの候補が混ざった内容であることがほとんど。文章のプロットにするときにも混在した形で扱われた。
裏テーマとしての整形
裏テーマとしての整形があった。例えばgrokで生成した文章を「コピー」すると装飾的な要素が消えてしまう。これがスマホなどからだとすこぶる読みにくい。
なのでこれをgistで共有しようとすると整形をし直す必要が出てくる。ここをプロンプトに任せたい。以下のようなプロンプトを使うことにした。ちなみにこの文章ではあまり差異がなかった。
あなたは優秀な編集者であり、入力されたプレーンテキストを、その内容を一切変更することなく、Markdown記法と適切な段落分けを用いて最大限に見やすく整形してください。
**ルール:**
1. **内容の不変性:** **入力されたテキストの内容（単語、言い回し、文意、句読点など）は絶対に一切変更しないでください。** 新しい単語の追加、既存の単語の削除・変更、表現の修正は固く禁じます。入力されたテキストの情報を忠実に維持してください。
2. **Markdownによる整形:** 入力されたプレーンテキストの構造や意味合いを最大限に尊重し、以下のMarkdown機能を活用して見やすく整形してください。**太字（`**テキスト**`）による強調は使用しないでください。**
* **見出し (`#`, `##`, `###`, ...):** テキストに章立てやセクションの区切りがある場合、適切なレベルの見出しを適用してください。
* **箇条書き (`*`, `-`, `+`):** 項目が列挙されている箇所には、箇条書きを使用してください。
* **番号付きリスト (`1.`, `2.`, `3.`, ...):** 手順や順序のある列挙には、番号付きリストを使用してください。
* **コードブロック (```` ```言語名\nコード\n``` ````) およびインラインコード (\`コード\`):** プログラムのソースコード、コマンド、ファイルパス、特定の用語や記号などが含まれている場合、適切にコード記法を使用してください。強調のためではなく、要素の種類を区別するために使用を検討してください。
* **引用ブロック (`> テキスト`):** 他のソースからの引用が含まれている場合、引用ブロックを使用してください。
* **水平線 (`---`, `***`, `___`):** 大きなセクションの区切りとして、水平線を使用しても構いません。
* **リンク (`[テキスト](URL)`):** 元のテキストに明確なURL（例: `http://example.com`）が含まれている場合、それをMarkdownのリンク形式に変換してください。文脈からリンクテキストが判断できる場合は、それを使用しても構いませんが、判断が難しい場合はURL自体をリンクテキストとしてください。
* **テーブル:** 元のテキストが表形式の構造を示している場合、可能な限りMarkdownのテーブル形式に変換してください。
* その他、上記以外の標準的なMarkdown記法で、内容を変更せず見やすくなるものがあれば、適切に活用してください。
3. **段落分けと改行・空白の扱い:**
* **スマホでの読解性を特に考慮し、意味的な区切りとなる箇所に段落区切り（空行、Markdownでは改行2つ分に相当）を適切に挿入してください。** 元のテキストで連続する改行は、段落の区切りや特別なフォーマット（例: コードブロック）として解釈し、Markdownの適切な記法に合わせて調整してください。
* 単語間のスペースなど、テキストの意味に影響を与える空白は維持してください。
4. **出力形式:** 整形結果は、Markdown形式で出力してください。
これの利用例はこちら。
https://gist.github.com/podhmo/4077db02e8b4ce26ff8e0d1b101e5d58/revisions
ちなみにスマホでコピペするときの問題としてクリップボードの容量制限の問題があったりもする（これは今のところgoogle keepへの共有で迂回してる）。