■ 1. 発表概要
- 登壇者: mizchi（フリーランスエンジニア）
- 発表会: Zennfes Spring 2026
- 主題: AI時代に、人間が技術記事を書く意味を問い直す
- 登壇者の専門領域:
- パフォーマンスチューニング
- AIパイプラインによる開発自動化
■ 2. AI以前・以降の技術記事の変化
- AI以前の技術記事の役割:
- 翻訳・キュレーション・学習ログを兼ねる言語障壁の埋め合わせ
- 二次情報ゆえに利用者視点の解釈が混ざりやすい
- 日本コミュニティにおけるフリーライダー傾向
- AI以降の変化:
- 全方位にレバレッジの効くAIだけ触れば事足りる状況になった
- 人間は技術記事の一次消費者ではなくなった
- AIが書き、AIが読む。人間はAI越しに要約を読むだけになった
- 消費フローの比較:
- AI以前: 人間が書く → 人間が読む → 人間が学ぶ
- AI以降: AIが書く → AIが読む → 人間は要約だけ
- 問い: AIがAI向けに説明するフローでは、既存の技術記事の存在理由はなくなる
■ 3. AI周辺ツール記事の賞味期限問題
- 書いている間に前提が更新され、公開した頃には標準機能に吸収されている
- 賞味期限が短い記事の類型:
- AI bikeshed: エージェント設定いじりの記事（.vimrcの現代版）
- absorbed: 知見は次のモデル・ハーネスに吸収される
- translation: 翻訳性能の向上で、紹介・翻訳の二次情報が不要になった
■ 4. 技術記事とスキルの等価性
- 良い技術記事と良いスキルに求める要件は一致する:
- 問題が解決する（読者の課題が解ける / タスクが完了する）
- 再現性がある（手順通りで再現できる / 誰が実行しても同じ結果）
- 新規性がある（既知の焼き直しでない / 既存手順の焼き直しでない）
- 結論: article.md をSKILL.mdに置き換えることが可能
- mizchiのスキル運用例（github.com/mizchi/skills）:
- skill-selector: プロジェクト構成から必要なスキルを選び、設定を生成・更新
- empirical-prompt-tuning: スキルを定量評価して自己改善する
- retrospective-codify: 現在のセッションから一般化できるスキルを抽出する
- Hermes Agent（NousResearch）のSkillsシステムとの整合:
- スキルはエージェントの手続き的記憶（procedural memory）として機能する
- エージェント自身がスキルの作成・更新・削除を行う
- ターン後の自己改善レビューでも、スキルを自動で書き足す
■ 5. 人間にとっての知識単位とAIの差異
- AIの知識単位: スキル（再現可能・機械実行可能・揮発しても再生できる）
- 人間にとって良い記事の要件:
- 新しい概念の獲得
- 新しい視点を得て、創発を刺激すること
- 記憶に刻むための叙情的なレトリック
- AIの学びを自動化したら、人間が関与する余地がなくなった
■ 6. 言語化の本質と難しさ
- AIから人間への要求は2つに集約される:
- ゴールを言語化する（そのために必要な資料やスキルを選別すること）
- 有益な対話相手になる（目的の言語化、曖昧性の排除、ミスの指摘）
- 言語化を過小評価することへの警告:
- 暗黙知が暗黙なのには相応の理由がある
- 言語化できた瞬間に、それは暗黙知ではなくなる
- 専門家として暗黙知を記述するのが、知の最前線
- 「直感的」はNG WORD（根拠を示す必要があるため）
- 参考: Polanyi (1966) The Tacit Dimension / 野中・竹内（1995）SECIモデル
- LLMとの非対称性:
- LLMはセッション中に高速にドメインを構築し、揮発する
- 当人が自明なことは書かない
- 「十分に賢いなら自然と導かれる結論」のレベルが上がる
- 結果として人間が置き去りにされる（認知的敗北）
■ 7. AIからドメイン知識を抽出する方法
- method 01: わかるまで質問責め
- 王道だが人間側に高負荷
- 理解できたか計測できない
- method 02: ブラックボックスで分割統治
- 現実解だが、コアドメインはリスク
- API契約に設計力が必要
- method 03（推奨）: 多角的な解析
- BBテスト・性能計測・監査
- 外側から性質を炙り出す
- マクロ分析ツールが不足している領域
■ 8. プログラマの言語化実践
- プログラマの言語化 = 分析ツールを作る（コードの扱い方という暗黙知を実装で表現する）
- 実践フロー:
- 01 AIにツールを作らせる
- 02 出力の妥当性を経験で評価
- 03 使わせて反復改善
- 04 有用性・再現性が確認できて記事化
- 登壇者が実際に作成したツール（一部）:
- sprawlens: コード変更差分を地理データとして可視化（mizchi.github.io/sprawlens）
- similarity: 木構造の編集距離から、コード重複を検出
- ts-fuzzing: TS型定義から関数・コンポーネント入力をfuzzing
- flaker: CI上で不安定なテストの検出と分類
- lightbringer: playwright-testのステップ毎にCPU・IOを計測
- chaosbringer: playwright経由でランダムに障害を注入するカオステスト
- vlmkit: VRTヒートマップをDOM・CSSに対応付け、構造化
- mnemo（試作）: HermesのメモリシステムをMoonBitで実装、AI同士が知識をスキルへ蒸留する仕組み
■ 9. アイデアの検証サイクル
- 検証コストが暴落した時代のアイデアの回し方:
- アイデアを検証するコストが大幅に下がった（Simonton (1997) equal-odds rule）
- 新しいアイデアは学習と創発のサイクルの中にある（Kolb (1984) Experiential Learning）
- ただし、学習とは認知への負荷である（Sweller (1988) Cognitive Load Theory）
■ 10. 専門家が今書くべきこと
- 専門家のレビューと評価が、AI時代における技術記事の価値:
- 一次資料はポジティブなことしか書かない
- 検証はコミュニティの仕事
- 技術記事の一番の価値は、採用後の推移と失敗談の共有にある
- AI時代に専門家のレビューを成立させる二つの前提:
- 価値あるフィードバック: 使い手である人間が、AIにとって価値あるフィードバックを出せること
- AI前提で再構築する: プログラミングのフロー自体を見直し、ツールチェイン・エコシステムをAI前提で作り直す
- AI時代の変化の整理:
- 下がったもの: 学習コスト（難解な技術も踏み倒せる）、参入障壁（個人でOS・DB・言語さえ作れる）
- 変わらない・むしろ上がったもの: 要求水準、使い手への要求、評価サイクルの速度
- 下がった障壁と変わらない要求のギャップを埋めるのが専門家の仕事
■ 11. まとめ: AIに価値あるパートナーであり続けるために
- 認知的敗北を喫さず、学びを続ける
- AIに使われるな、使いこなせ
- 知識を抽出して、コミュニティに還元しろ