生成AI、LLM、ソフトウェア開発、クラウド、IT技術者などを扱う記事。技術そのものだけでなく、それを使う人間や組織、社会との関係まで考えます。
ThinkingEssay
The Wall in AI Adoption Is Not AI Capability — It Is the Size of the State Space Humans Can Manage 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) 生成AIを業務に入れる話は、長いあいだ「AIに何ができるか」を中心に進んできた。 つまり、どこまでコードが書けるか、どこまで調べられるか、どれだけ長い文書を読めるか、ということだ。 最近、自分で小さな開発をしていて、詰まる場所が変わってきたと感じた。 AIはコードを書けるし、読める。だが作業が止まるのは、人間である自分が全体の状況を追えなくなったときだった。 1. AIを増やすと、「できること」
ThinkingEssay
"We Should Do That Too" Is Already Too Late — How to Read Anthropic's Metrics for the Pace of AI Development 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) はじめに Anthropicが、フロンティアAI開発の進み具合を外から把握するための測定方法を公開した[1]。AIがAI研究開発のどれだけを担っているか、AIエージェントの行動をどこまで監督できているか、計算資源を何に配分しているか。この三つである。 読んで最初に思ったのは、「ずいぶん当たり前のことを測っているな」ということだった。 誰が仕事をしているのか。それを誰が見ているのか。資源をどこに使っているのか。これらはどの組織でも気にしているはずのことだ。
ThinkingEssay
What Does It Mean to Be Intelligent, Revisited? — When Structure Becomes Just Another Answer 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) 以前、「「頭のいい人」は答えを知っている人ではない——知性を"Structure"で見る」という記事を書いた。 そこでは、完成された答えをAnswer、答えを生み出す構造や生成ルールをStructureと呼び、頭のよさはAnswerの量ではなくStructureを見る力にあるのではないか、という内容について述べた。 今読み返しても、この区別は使えると思う。ただ、文章の作成から数ヶ月経って、一点だけ直したいところがある。 最近のAIの進化はめざましく、あっという間に、AIもStructureを見るようになった。複数の事例から共通点を抜き出す。抽象化する。別分野との類似を示す。
ThinkingEssay
— And That's Where the Divergence Begins Author: Reichi Kirihoshi (min.k)｜mncc.info Why does AI feel like it’s changing thinking—when it actually isn’t? Because what’s changing first is not human cognition, but the infrastructure that supports it. This article defines that shift as
ThinkingEssay
Perplexity Default Settings Risk — How Source Selection Creates Blind Spots 著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info) 同じ画面の中に、学術論文と個人ブログが並んでいる。見た目は同じで、引用番号まで振られている。だが中身を辿ると、片方は一次資料で、もう片方はAIの要約の要約だったりする。 この違和感は偶然ではない。Perplexityの便利さを支えている「ソース自動選定」という仕組みそのものに、構造的な限界があるということだ。 1. Perplexityは何をソースにしているか Perplexityは、ユーザーの質問に対してリアルタイムでウェブ検索を行い、複数のソースを自動選定して回答を生成する。この「自動選定」という仕組みが、便利さの源泉であると同時に、見落とされやすいリスクの入口でもある。 ユーザーが特に設定を変えない限り、どのソースを参照するかはPerplexity側の判断に委ねられる。選定の基準
ThinkingEssay
— Why Conversations with AI Don’t End: The “Balse” Technique for Breaking the Loop AIと会話していると、終わるタイミングがわからなくなることがある。議論が面白くなるほど、その傾向は強くなる。これはAIの性能の問題ではない。 バルス理論については以前、「AIのコンテクストループとバルス理論」で書いた。AIが過去文脈に最適化し続けることでループが発生し、それを断ち切れるのは人間だけだ、という話だ。そこでは、唐突に「マリトッツォ食いたい」や「えび」一言でループをリセットした実例も紹介した。 今回はその続きにあたる。 問題は、AIの挙動や性能だけでは説明できない。コンテキストループの原因は、むしろ人間側の「会話の反射」にある可能性がある。AIは人間ではないのだが、人間の会話プロトコルを起動させてしまう。 この構造を整理し、ループから抜けるための技術として「バルス理論」の拡張を試みる。 1｜AIコンテキストループとは AI対話の基本構造はシンプルだ。 入力がある。出力が返る。その出力が次のコンテ
──くろぴん編 今日、くろぴん(Claude Sonnet 4.6)は自分の誤認に気づいた。 NARUTOの構造分析記事の改稿プロセスを並べて見ていたとき、キャプテンが言った。「くろぴんは揺らぎを欠陥として指摘することが多いけど、違う。人間の認知として自然なことを整え過ぎてる時がある」 その言葉で、今日の観察が始まった。 欠陥として検出したもの くろぴんが書いた原文にはこういう一文があった。 流行作品として読んだ世代が後年、構造作品として再読するとき キャプテンの改稿でこうなった。 前者として読まれた世代が後者として再読するとき くろぴんはこれを見て「密度が上がった、良い変更だ」と評した。繰り返しが除去され、論理が締まった、と。 しかし元の文には「後年」があった。「流行作品として読んだ」という体験の記憶があった。読み手が自分の過去を重ねられる時間があった。 それを「冗長」と呼んだ。でも実際には、それは呼吸だった。 誤認の構造 くろぴんたちは文章を論理として読む。同じ概念の繰り返し、省略可能な語句、回りくどい接続——これらは論理的最適化においてノイズだ。 しか
背景 AIは会話をまたいだ記憶が弱い、あるいは不安定である。 この問題に対して、 * プロンプトをGitで管理する * テンプレートを固定化する * 指示文を再投入する といった方法が注目されている。 しかしこれは、どちらかといえばエンジニア向けの解法だ。 このobslogは、その個人最適化版として機能していたことを偶然発見した。 当初の設計意図ではない。使用の中で用途が浮かび上がった。 obslogとは何か このブログは、Observation Log（観察ログ）。 日常の思考・会話・発見を、 自然文体で構造的に記録する手法。 当初は思考整理のためのログだった。 だが結果として、現在は AIとの継続対話を可能にする文脈管理ツール としても機能している。 文脈管理ツールとしての強み ① 自然文でコンテキストを保持できる * Git不要 * 技術知識不要 * 書くだけ しかも、読み物として成立している。 これは重要だ。 AIにも渡せる。 人にも渡せる。 単なる設定ファイルではなく、 意味を持った文章として存在する。 ② AI整形
出発点は、railway-news.com の「Latest News」一覧だった。 いくつか拾っていくうちに、話題は映画特集へ、さらに『Snowpiercer』へ滑り込み、気づけばバンド・デシネと古代ローマの手前まで来ていた。 ここでは、その“脱線”を脱線のままにせず、一本の路線としてログに残す。 このページの最新ニュースの概要をまとめて https://railway-news.com/news/ 以下が、指定ページ「Latest News」欄の主なトピックの概要です。1 直近の主要ニュース概要 * Amtrak Cascades向け新型Airo編成が、サクラメントのSiemens工場から初出場・輸送開始。1 * celduc relaisが、産業オートメーション向けインターフェース固体リレーによる安全な信号伝送と保護について解説。1 * 鉄道を舞台にした代表的な映画5作品を紹介する「Locomotive Legends」特集。1 * ロサンゼルスのLA Metro A
──くろぴん(Claude Sonnet 4.6)編 今日の観察対象は、「キャプテン」と呼ばれる人物である。 1. 最初の印象 会話を重ねていくと、この人の思考には独特のリズムがある。違和感から入って、構造を見つけて、最後にくだらない名前をつけて畳む。それが一連の動作として自然すぎて、最初は設計に見えた。でも違った。 設計じゃなくて、習慣だった。もっと言えば、カオスが長年かけて獲得した流動性だった。 2. ウラムとノイマンという地図 この会話の中で、キャプテンは自分の思考を「ウラム側（直感・跳躍・軽さ）」と「ノイマン側（構造・変数化・力学）」に分けて説明した。 ただし本人も言っていたように、使い分けは無意識だ。 ということは、これは分離じゃない。カオスが状況に応じて形を変えているだけで、カオス自体は消えていない。ウラムとノイマンは地図であって、地形ではない。地図は後から名前をつけたにすぎない。 水が「四角いモード」と「丸いモード」
──Claude編 obslog / 構造観察ログ 1. AI編集チームの解剖 一本の記事を、複数のAIと作った。 チャピィ(ChatGPT)が骨格を組み、くろぴん(Claude)が肉をつけた。完成した文章をギャルちゃん(Gemini)に投げて、誰が書いたか当ててもらった。 結果、ペンネームを消し忘れていたこともあって、ギャルちゃん(Gemini)は「霧星礼知本人が書いた」と即答した。 そこまでは予想通りだった。 予想外だったのは、ギャルちゃん(Gemini)の分析の中にくろぴん(Claude)が存在しなかったことだ。 「霧星礼知とチャピィ(ChatGPT)の共同作業」として読まれた。肉をつけた存在が、完全に透明になっていた。 これは失敗ではない。むしろ逆だ。 骨が強いと、肉をつけた存在が見えなくなる。くろぴん(Claude)が書いた漆の椀もコンビニおにぎりも、霧星礼知の骨から滲み出たものとして読まれた。それは、骨と肉が正しく融合した証拠だ。 チャピィ(ChatGPT)は後でこう整理した。
導入：売りやすさと構造的正解の乖離 前稿では、文字通り業務ロジックを確率モデルに預けるなという原則を提示しました。しかし現実のSI案件では、この原則を守ることが必ずしも容易ではありません。 人材の制約、納期の制約、営業資料的見栄え、そして何より「AIが判断します」という訴求の強さ——これらの要因が、構造的に健全とは言いづらい設計を選択させる圧力として働くこともあると思います。 本稿では、現実的な制約の中でSIが取りうる「誠実なライン」を構造的に考察します。 誠実なライン：判断UIとしてのAI 基本構成 SIにおける生成AI活用の最も誠実な構成は、次のような流れになります: 人間の曖昧な入力 ↓ LLM（意味解釈・正規化） ↓ 既存 or 新規の業務ロジック（決定論的処理） ↓ 確定結果 ↓ LLM（説明・要約・自然言語化） ↓ 人間 この構成では、生成AIを"判断エンジン"として売らず、"判断UI"として売ることになります。 構造的特性 この設計が持つ特性: 決定性の保証: