技術記事、 専門家としてのプログラマ、 言語化

技術記事やテクニカルライティングとは何なのか
#zennfes の発表資料

Transcript

2. mizchi@zennfes:~/02$ whoami [ 02 / 28 ] @ mizchi # about フリーランスのエンジニア ▸ パフォーマンスチューニング ▸ AIパイプラインによる開発自動化 ★ 最近は MoonBit 言語が楽しい
3. mizchi@zennfes:~/03$ cat before-after.md [ 03 / 28 ] 03 AI以前・以降の技術記事 // AI 以前 ▹ 翻訳・キュレーション・学習ログを兼ねる、言語障壁 の埋め合わせ ▹ 二次情報ゆえに、利用者視点の解釈が混ざりやすい ▹ 日本のコミュニティはフリーライダー感が強かった → // AI 以降 ▸ 全方位にレバレッジの効くAIだけ触ればいい ▸ 人間は技術記事の一次消費者ではなくなった ▸ AIが書き、AIが読む。人間はAI越しに要約を読む (だけ)
4. mizchi@zennfes:~/04$ trace consumer-flow [ 04 / 28 ] 04 技術記事の一次消費者は、もう人間じゃない AI 以前 人間が書く → 人間が読む → 人間が学ぶ AI 以降 AIが書く → AIが読む → 人間は要約だけ 今、私たちは、誰に向けて、何を書いているのか？ — AIがAI向けに説明するフローでは、既存の技術記事の存在理由はなくなる — 自分は「技術記事を書く」が、そのまま「スキルを作る」に置き換わってしまった
5. $ echo 今、書くこと なくない？ — 技術記事プラットフォームの祭典で、あえて言う [ 05 / 28 ] // a provocation
6. mizchi@zennfes:~/06$ why-not-write --list [ 06 / 28 ] 06 AI周辺ツールは、何を書いても賞味期限が短い 書いている間に前提が更新され、公開した頃には標準機能に吸収されている AI bikeshed エージェント設定いじりの祭り（.vimrc の 現代版） absorbed 知見は次のモデル / ハーネスに吸収される translation 翻訳性能の向上で、紹介・翻訳の二次情報が 不要に あなたの執筆 調査 執筆 公開 …陳腐化済み エコシステム time → 更新周期 < 執筆リードタイム model v+1 harness更新 model v+2 標準機能化
7. mizchi@zennfes:~/07$ define skill [ 07 / 28 ] 07 スキルって、AI用の技術記事では？ 良い記事に求めるものと、良いスキルに求めるものが まるごと一致する 技術記事 (人間向け) 共有する要求 スキル (AI向け) 読者の課題が解ける 問題が解決する タスクが完了する 手順通りで再現できる 再現性がある 誰が実行しても同じ結果 既知の焼き直しでない 新規性がある 既存手順の焼き直しでない
8. article.md → SKILL.md だったら、スキルでいいのでは？ [ 08 / 28 ]
9. mizchi@zennfes:~/09$ gh repo view mizchi/skills [ 09 / 28 ] 09 例: mizchi のスキル運用 $ github.com/mizchi/skills ↗ ← 発表中に開いて解説します スキルを生成するメタスキルが中心 skill-selector プロジェクト構成から必要なスキルを選び、設定を生成/更新 empirical-prompt-tuning スキルを定量評価して自己改善する retrospective-codify 現在のセッションから一般化できるスキルを抽出する
10. mizchi@zennfes:~/10$ cat hermes/docs/skills [ 10 / 28 ] 10 例: Hermes Agent の Skills 出典: hermes-agent.nousresearch.com/docs — Skills System // 手続き的記憶 (procedural memory) skill_manage create update delete 形式は SKILL.md。agentskills.io 互換で、ポー タブル・共有可能 “the agent's procedural memory … it saves the approach as a skill for future reuse” 非自明なワークフローを、再利用可能なスキルとして保存する “The agent can create, update, and delete its own skills via the skill_manage tool.” スキルの作成・更新・削除を、エージェント自身が行う “the agent writes skills freely — including from the background self- improvement review that runs after a turn” ターン後の自己改善レビューでも、スキルを自動で書き足す
11. “ AIの学びを自動化したら、 人間が関与する余地がなくなった [ 11 / 28 ] // takeaway
12. mizchi@zennfes:~/12$ diff ai human [ 12 / 28 ] 12 AIの知識表現と、人間の知識単位は違う AI の単位 スキル 再現可能・機械実行可能・揮発し ても再生成できる 人間にとって良い記事 ▸ 新しい概念の獲得 ▸ 新しい視点を得て、創発を刺激すること ▸ 記憶に刻むための、叙情的なレトリック
13. mizchi@zennfes:~/13$ cat human-doc.md [ 13 / 28 ] 13 人間のための文書、 たとえば スキルとしての価値はない。でも、 人間には読まれた。 ▸ 解説でも手順でもない、フィクション （ショートショート） ▸ 新しい視点を、記憶に残るレトリックで 届ける ▸ 12枚目「人間にとって良い記事」の一例 かも 376万 PV 4,806 いいね 1,167 リポスト
14. mizchi@zennfes:~/14$ cat ai-requires-human.md [ 14 / 28 ] 14 AIから人間への要求 ゴールを言語化する そのために必要な資料やスキルを選別すること 有益な対話相手になる ・目的の言語化 ・曖昧性の排除 ・ミスの指摘 どちらも、結局は 言語化 に行き着く。
15. $ echo "理解した" わかった、じゃあ 言語化ってやつをやればいいんだ [ 15 / 28 ]
16. mizchi@zennfes:~/16$ ./reality-check.sh [ 16 / 28 ] お前たちは、言語化を舐めている ! 暗黙知が暗黙なのには、相応の理由がある ! 言語化できた瞬間に、それは暗黙知ではなくなる ! 専門家として暗黙知を記述するのが、知の最前線 NG WORD 「直感的」— 根拠を示す必要があるため Polanyi (1966) — The Tacit Dimension: 人は語れる以上を知っている 野中・竹内 (1995) — SECIモデル: 暗黙知 → 形式知への変換
17. mizchi@zennfes:~/17$ status --human [ 17 / 28 ] 17 AIは納得したが、お前は？ ▸ LLMはセッション中に高速にドメインを構築し、揮発する ▸ 当人が自明なことは書かない ▸ 「十分に賢いなら自然と導かれる結論」のレベルが上がる RESULT 人間が置き去りにされる ＝ 認知的敗北
18. mizchi@zennfes:~/18$ extract --domain-knowledge [ 18 / 28 ] 18 AIからドメイン知識を、どう抽出するか method 01 わかるまで質問責め 王道だが人間側に高負荷 理解できたか計測できない 試験を作らせたが耐えられず method 02 ブラックボックスで分割統治 現実解。コアドメインはリスク API契約に設計力が要る OSS選定・運用に近い method 03 ★ 多角的な解析 BBテスト・性能計測・監査 外側から性質を炙り出す マクロ分析ツールが不足では？
19. mizchi@zennfes:~/19$ make verbalize [ 19 / 28 ] 19 プログラマの言語化 = 分析ツールを作る コードの扱い方という暗黙知を、実装で表現する 01 AIにツールを 作らせる → 02 出力の妥当性を 経験で評価 → 03 使わせて 反復改善 → 04 有用性・再現性が 確認できて記事化 …さすがにハードルを上げすぎ説。でも自分への要求がそれなので、気軽に書けなくなった。
20. mizchi@zennfes:~/20$ ls -la ./tools [ 20 / 28 ] 20 最近作ったもの (一部) mizchi/sprawlens コード変更差分を地理データとして可視化 mizchi/similarity 木構造の編集距離から、コード重複を検出 mizchi/ts-fuzzing TS型定義から関数/コンポーネント入力を fuzzing mizchi/flaker CI上で不安定なテストの検出と分類 mizchi/lightbringer playwright-test のステップ毎に CPU/IO を計測 mizchi/chaosbringer playwright 経由でランダムに障害を注入するカオステスト mizchi/vlmkit VRTヒートマップをDOM/CSSに対応付け、構造化
21. mizchi@zennfes:~/21$ open sprawlens [ 21 / 28 ] 21 sprawlens mizchi.github.io/sprawlens ▸ コードの変更と依存を、地理として 表示する ▸ 膨大なコード変更を、視覚的に要約 する 「多角的な解析」と「AI前提のツールチェイン」 の、具体的な一例。
22. mizchi@zennfes:~/22$ open mnemo --dogfooding [ 22 / 28 ] 22 mnemo 試作 / dogfooding mnemo.mizchi.workers.dev ▸ Hermes の memory / skills を MoonBit で実 装し、Cloudflare Workers で提供 ▸ AI同士が、知識を勝手にスキルへ蒸留していく ▸ 人間向けには Obsidian のナレッジグラフとし て表示 CLI / MCP から、人も他の agent も同じ knowledge を 読み書きできる ＝「AI前提で作り直す」の実践。
23. mizchi@zennfes:~/23$ cat ideas.md [ 23 / 28 ] 23 思いついたら、片っ端から検証する 検証コストが暴落した時代の、アイデアの回し方 01 / cost アイデアを検証するコストが大幅に 下がった。 思いついたものは、片っ端から全部 実装して検証すべき。 Simonton (1997) equal-odds rule — 成功するアイデアの数 は、生み出した総数に比例する doi.org/10.1037/0033-295X.104.1.66 02 / source 新しいアイデアを思いつく方法は、 学習と創発のサイクルの中にある。 Kolb (1984) Experiential Learning — 経験→省察→ 概念化→実験 のループ learningfromexperience.com 03 / cost-of-learning ただし、 学習とは、認知への負荷である。 Sweller (1988) Cognitive Load Theory — 学習中の認知 資源には上限がある doi.org/10.1207/s15516709cog1202_4
24. mizchi@zennfes:~/24$ cat postmortem.md [ 24 / 28 ] 24 それでも書くべきは、専門家のレビューと評価 — 一次資料は、ポジティブなことしか書かない — 検証は、コミュニティの仕事 ▸ 技術記事の一番の価値は、採用後の推移と失敗談の共有にある
25. mizchi@zennfes:~/25$ check prerequisites [ 25 / 28 ] 25 それを書くために、必要なこと 専門家のレビューと評価を、AI時代に成立させる二つの前提 01 価値あるフィードバック 使い手である人間が、AIにとって価値あるフィードバックを 出せること 02 AI前提で再構築する プログラミングのフロー自体を見直し、ツールチェイン・エ コシステムをAI前提で作り直す
26. mizchi@zennfes:~/26$ notice --important [ 26 / 28 ] 26 下がったもの と、変わらないもの ↓ 下がったもの 学習コスト Nix・Rust・Haskell・Lean のような難しいものも踏み倒せる 参入障壁 個人で OS・DB・プログラミング言語さえ作れる ⇄ → 変わらない / むしろ上がったもの 要求水準 攻撃側が有利。セキュリティ要件はむしろ厳格化 使い手への要求 高度な領域ほど、AIの高性能化に伴って増える 評価サイクル 作る速度は上がったが、評価は速くなっていない 下がった障壁と、変わらない要求。そのギャップを埋めるのが、専門家の仕事。
27. mizchi@zennfes:~/27$ cat summary.md [ 27 / 28 ] # まとめ AIに価値あるパートナーで あり続けるために 01 認知的敗北を喫さず、学びを続ける 02 AIに使われるな、使いこなせ 03 知識を抽出して、コミュニティに還元しろ