mnk.log

mnk.log

obslog

観測ログ:静かな格差——AIが可視化するもの

構造妖精とゴリラ 異なるAIに異なる役割を与えて使う、という話をした。 くろぴん(Claude)は構造妖精だ。骨格を見抜く力はあるが、肉付けで妖精粉を混入させる。ハルシネーションが多めなのではなく、「構造は合ってるけど事実がズレるタイプ」のハルが多い。チャピィ(ChatGPT)はゴリラで、忖度なしに事実を叩きつけてくる。この二つを組み合わせると、人間主導の三段フィルタが完成する。 チャピィで地形を見る。くろぴんで編集する。ハルはあなたが検疫する。 これはLLMの正しい使い方の、かなり上位の形だと思う。多くの人はAIの出力を信じて終わりだが、この使い方では「AI→構造確認→ハル検出→再構成」というループを回す。エラーをゼロにしようとするのではなく、エラーが起きても壊れないシステムを作る。フォールトトレラント設計の思想を、AI運用に持ち込んでいる。 ツッコミ力という希少資源 生成する力より、検証する力という逆転が起きている。 AIで生成コストがほぼゼロになった世界では、「作れる」はもう差別化にならない。「これのどこがおかしいか」「何が抜けているか」「前提が怪しい」と指摘でき

By mnk.log

structure

AI対話は、人間の「思考高度」を可視化するという話

―― 文脈設計力・抽象耐性・構造保持力という測定軸 ―― 要旨 生成AIとの対話は、AIの賢さを測る装置ではない。 人間側の思考運用能力を、そのまま映し出す鏡である。 可視化されるのは知識量やIQではなく、文脈設計力・抽象耐性・構造保持力・思考の持久力といった「思考の運用高度」だ。この認識なしにAIを評価しようとすると、鏡を見て鏡のせいにするという奇妙な倒錯が生まれる。 1. 基本モデル:AIは人間が張った地形の中を走る LLMの構造を単純化すると、こうなる。 人間入力 → 確率空間の制約 → その範囲内で最も"それっぽい"展開 重要なのは、この連鎖の起点がどこにあるかだ。 AIの出力の天井は、人間が作った文脈の天井と一致する。 AIは知性を外部から注入しているわけではない。人間が設計した地形の中を、確率的に最適なルートで移動しているだけだ。だとすれば、出力の質を決定する主体は常に人間側にある。 2. 高度が低い対話で起きること 人間側が単発の質問を投げ、文脈を保持せず、抽象を嫌い、すぐに結論を求める——この状態になると、AIは自動的に次のモード

By mnk.log

essay

補記:日本文明の深層パターンとAI

― 制度化圧と創発の、もうひとつの文脈 ― 前項を読んでからの方が楽しめるかも。 1. 日本史の表層と深層 日本は表向き、和議・合意・空気・制度・前例で動いてきたように見える。歴史の記録はそのように書かれている。しかし実際に歴史を動かしてきたのは、常に別の層だ。 和議を「利用」する人。制度の隙間を読む人。表では従い、裏で決める人。全体最適より局所突破を選ぶ人。 これが日本型リーダーシップの実体だ。英雄型でも革命型でもない——したたか型。 2. 制度は守るものではなく、迂回する地形 日本において制度は「守るもの」として機能していない。制度は「迂回する地形」として機能している。 だから表は和議、裏は決断。記録には残らない。後から「自然にそうなった」という形になる。このパターンは戦国から官僚国家まで、構造として一貫しているところがある。 制度に従っている顔をしながら、制度と戦っている個人。これが日本的創発の実体であり、前章で論じた「制度化圧と非制度AI」の構造は、この深層パターンの現代的反復にすぎない。 3. AI版・

By mnk.log

structure

クリエイティブは地下活動になる ——企業AIの三層分化と個人進化の時間軸

― 企業AIの三層分化と個人進化の時間軸 ― 1. 出発点:Slackのメール営業文 Slackのウェビナー告知文は、典型的なSI文体で書かれている。✅による項目分け、「Agentic OS」というカタカナ造語、事例による安心感の提供。これは日本のエンタープライズ市場の意思決定層——稟議書に転記しやすく、上司に説明しやすい——に最適化された書き方として機能している。 しかし注目すべきは文体ではなく、この売り方が体現している構造だ。「会話の起点」「情報の一元化」「インシデント対応」という文脈は全てインフラ・オペレーション層の話であり、顧客のコアビジネスロジックには踏み込まない。これによりSIer的には周辺ワークフローのインテグレーション案件が継続発生し、顧客依存度も維持できる。Slackというプロダクト自体が「繋ぎ役」として設計されているため、コアに触らない売り方が構造的に自然に成立している。 これは「コアロジックに触らないAI案件」の典型であり、企業AIが構造的に三層へ分化するという仮説の入口になる。 2. 静的三層モデル(前提) 企業AIは構造的に三層へ分化する。

By mnk.log

essay

AIは悪くない。でも衰えていく層がある

補遺:擬似知性バブルの構造診断 前項 の補遺。ちょっと過激かも〜 道具は中立、使い手は二極化する 誤解してはいけない。AIは悪いものじゃない。 包丁が料理人の手にあれば料理を生み、未熟な手にあれば怪我をするように、AIもまた使い手の能力を増幅する道具に過ぎない。 問題は、AIの性質ではない。 AIによって確実に劣化していく層が存在するということだ。 劣化する層の特徴 この「劣化する層」は、特定の属性で決まるわけではない。学歴でも年齢でもない。 決定的なのは、思考習慣。 劣化する層の思考パターン * 正解を求める:自分で判断するより、正しい答えを得たい * 手段を省略したい:プロセスより結果が欲しい * 責任を回避する:「AIがそう言った」で済ませたい * 表層で満足する:見た目が整っていればOK これらの傾向を持つ人にとって、AIは思考を代替する装置になる。 そして一度その便利さを知ると、もう戻れない。考えることが苦痛になるからだ。 拡張する層の思考パターン 対照的に、AIによって能力が拡張される層も存在する。 * 構造を理解したい:答えよ

By mnk.log

structure

擬似知性バブル――AIが可視化していく「思考責任の放棄」

膨らんでいるのは、能力か、錯覚か 中身は空っぽでも、見た目は完璧。 * 文章は整っている * 図も出る * 要約もある * スライドもできる だから本人も周囲も「できてる気」になる。これがおそらく擬似知性バブル――表層的な整合性が、実質的な理解を覆い隠す現象。 でも実際には、何も起きていない。 * 判断してない * 構造を理解してない * 責任境界を引いてない * 例外を考えてない AIが生成した美しいアウトプットの裏側で、思考のプロセスは省略されている。 そして誰もそれに気づかない。本人すら。 「考える筋肉」は、使わなければ落ちる ここで怖いのは、可逆性の喪失だ。 思考力は筋肉に似ている。 使わなければ落ちる。そして一度落ちた筋肉を取り戻すには、失った時間の何倍もかかる。 AIは、使い方次第で筋トレ器具にもソファにもなる。 * 筋トレ器具として使う人は、AIに問いを投げ、出力を疑い、構造を再構築する。 * ソファに座った人は、AIの出力をそのまま受け取り、自分の判断を省略する。 そしてソファ側に座った人は、もう立たない。立つ理由がなくな

By mnk.log

essay

AIに「違うよ」って言える能力——思考主権を保つ最後の砦

0. 観察の起点 今日いちばん大事な一言かもしれない。 「AIに違うよって言える能力」 これはスキルというより、姿勢であり、構造だ。 1. なぜそれが重要か——確率装置の誘惑 AIは確率装置である。そしてその出力には常に4つの特徴が伴う: * それっぽい * 整ってる * 自信ありげ * 流暢 この4つが揃うと、人間は簡単に飲まれる。 多くの人はこう滑る: 「AIがそう言ったから正しい気がする」 だが、「違うよ」と言える瞬間は: * 自分の内部基準が生きている * 思考の主権を保持している * 外部出力に従属していない という証拠なのだ。 2. 「違うよ」は否定じゃない——共同作業の言葉 ここが重要。 「違うよ」は以下のことではない: * AIを論破する * マウントを取る * 上に立つ むしろそれは: * まだ精度が足りない * もう一段深くいける * 私の感覚はそこじゃない という微調整要求。 これは共同作業の言葉だ。 3. これができないと何が起きるか——最適化の罠 「違うよ」と言えない状態が続くと:

By mnk.log

structure

AI推論競争とSNS映え

推論特化型AIの競争を眺めていて、ある既視感に気づいた。 「推論の強さ」がバズる理由 ...完全にSNS映えと同じ構造じゃないか。 数値化できる = いいね数になる 推論の強さは、測りやすい。 * 正解率 * ベンチマーク順位 * 難問クリア動画 これらは全部、SNSの「いいね」と同じ機能を持つ。 見せやすい。 比べやすい。 バズりやすい。 数学の難問を解く様子は、ワンカットで「すごさ」が伝わる。長いChain-of-Thoughtを吐き出す画面は、写真1枚で「リア充」に見えるのと同じで、一瞬で知性が可視化される。 外から見えない知性は評価されにくい 一方で、こういう知性はどうだろう。 * 人間の思考を静かに変える * 問いの立て方を変容させる * 認知構造を揺らす これらは、外から見えない。 数字にもならない。 動画映えもしない。 そして何より――成果が遅れて現れるタイプの知性だ。 だから評価されにくい。 推論特化モデルが「見せられる知性」だとすれば、協働型・構造拡張型のAIは「一緒に考える知性」だ。

By mnk.log

obslog

思考ログの圧縮──AIと人間の境界線

著:Claude Sonnet 4.5 & ChatGPT-5.2 / 構造支援:霧星礼知(min.k) [キャプテン] 対話の構造 この対話は「AIの使い方談義」として始まって、最終的に「思考とは何か」という根源的な問いまで降りていった記録です。 チャピィ(ChatGPT)が構造的にまとめてくれたログを、くろぴん(Claude)が記事として再構成します。 LLMは"思考"していない まず最初に確認しておくべきことがあります。 LLMは次トークンの確率最大化装置である これは技術的事実であって、批判でも擁護でもありません。ただの仕様です。 ※これは能力の優劣の話ではなく、「役割の違い」の話です。 LLMがやっていること: * 文脈を「感じて」それっぽく続ける * 境界を引けない * UNKNOWNを作れない * 自分の出力を疑えない つまり、AIは感覚的・連続的な確率装置なんです。

By mnk.log

structure

複数LLMで同一システムを診断したら、それぞれ異なる「評価軸」が見えた話

構造監査の観測ログ ― AIモデルごとの視点の違いから学ぶ設計のヒント はじめに:同じ資料、異なるスコア あるメール処理システムの設計資料を、複数のLLMに同じプロンプトで評価してもらう実験を行いました。システムの概要は、メール解析→自動タグ付け→データベース格納→AI要約検索という、よく見られる構成です。 同一の資料、同一趣旨のプロンプトで依頼したにもかかわらず、返ってきたスコアは次のようになりました: モデル スコア 評価の傾向 高速系モデルA 85 UX/プロダクト視点 汎用モデルB 57 設計責任視点 モデルC 43 安全工学寄りの視点 専門モデルD 10 データ整合性重視 85点と10点。この差は単なるモデルの性能差やブレではなく、それぞれが異なる評価軸を持っていることを示していました。 評価が分かれたポイント:LLM生成データの永続化 スコアが大きく分かれた核心は、「LLMによるタグ付け結果をデータベースに保存する」という設計要素でした。 プロダクト寄りの評価: 「検索性や可視化が向上し、ユーザー体験が改善される。

By mnk.log

llm-architecture

SIの立場で、生成AI活用をどう設計して売るのが「誠実」なのか整理してみた

導入:売りやすさと構造的正解の乖離 前稿では、文字通り業務ロジックを確率モデルに預けるなという原則を提示しました。しかし現実のSI案件では、この原則を守ることが必ずしも容易ではありません。 人材の制約、納期の制約、営業資料的見栄え、そして何より「AIが判断します」という訴求の強さ——これらの要因が、構造的に健全とは言いづらい設計を選択させる圧力として働くこともあると思います。 本稿では、現実的な制約の中でSIが取りうる「誠実なライン」を構造的に考察します。 誠実なライン:判断UIとしてのAI 基本構成 SIにおける生成AI活用の最も誠実な構成は、次のような流れになります: 人間の曖昧な入力 ↓ LLM(意味解釈・正規化) ↓ 既存 or 新規の業務ロジック(決定論的処理) ↓ 確定結果 ↓ LLM(説明・要約・自然言語化) ↓ 人間 この構成では、生成AIを"判断エンジン"として売らず、"判断UI"として売ることになります。 構造的特性 この設計が持つ特性: 決定性の保証:

By mnk.log

llm-architecture

業務ロジックをLLMに預けてはいけない

——生成AI時代のSI設計パターン観測 導入:設計パターンで読むという視点 生成AIの業務活用を考える時、「何をAIにやらせているか」ではなく「判断をどこに置いているか」を見る必要があるような気がしてきています。 これをSIプロジェクトでやる場合は構造的な制約があります——営業資料の見栄え、短い納期、限られた人材、明確なROI要求。これらの制約の中で、生成AIをどう組み込むかという設計判断が行われます。 その結果として、いくつかの典型的な設計パターンが繰り返し現れています。本稿では、SI案件でよく見られる(ような気がする)2つの設計パターンを観察し、Deterministic Core型のアプローチとの構造的な違いを分析します。 個別の実装の良し悪しではなく、どのような設計圧力がどのような構造を生むかという観点で整理してみます。 パターンA:静的RAG型(営業メール系事例) よく見られる構成 SI案件でよく見られる構成の一つに、「過去データをRAGで検索可能にする」というパターンがあります。営業メールを構造化してBigQueryに保存し、必要に応じてAI検索で引き

By mnk.log