Skill開発は、プログラミングなのか？

最近の私は、まだ慣れていないSkill開発に扉を開けただけ。「これはスキルになるのか？」からスタートします。

私のSkill開発を問う、最初のプロンプトがこれです。

最初の問い（問１）

Skill開発の試行錯誤のフェーズさえまだ先の話しです。入り口に立っています。昔やっていたプログラミングと似ています。FORTRANをはじめたばかりの頃の感じです。デバッカーを使えるような段階にさえ行けてない。このループを何か月も続けるしかなさそうです。

LLMへの問い（１）

構文暗記からアーキテクチャ・論理的思考へ

LLMは文脈を読み取って、いろいろなことを説明してくれました。思ったより、長い話しでした。その中に本質っぽい話しを発見しました。

「構文暗記からアーキテクチャ・論理的思考へ」、
「そもそも何を作ろうとしているのか」、
「システム全体がどう結合されているのか」、
これらを見抜くプログラミングの基礎力。

「構文暗記からアーキテクチャ・論理的思考へ」という段落がありました。これまでの手続き型や関数で作る手法から進化したAI時代だから使うべきプログラミング作法なのかな？と思います。

自信が持てない部分を確かめたい一心で、私は更に問いました。

次の問い・問2

Skill開発の手法や作法をもっと深掘りしてください。プログラミング言語を使って関数を書く、アジャイル開発、CI/CDなどを抽象化しただけでは、昔と変わりません。何かが違うように感じていますが、今の私にはその答えが何なのかが分かりません。AI開発を言語化してください。

LLMへの問い（２）

この問いに対するLLMの答え

その「何かが決定的に違う」という直感は、まさにソフトウェア工学が現在直面している最大のフロンティアそのものを突いています。結論から言うと、Skill開発は「単に関数化やアジャイル、CI/CDを自然言語で抽象化しただけ」ではありません。従来のプログラミング概念と相似形を成しつつも、土台となる計算モデルの前提が反転している点に本質的な違いがあります 。

ノートブックの学術論文や調査レポートが示している技術的な構造から、その「違いの正体」を深掘りしてみます。

１. 「関数（Function）」と「Skill」の決定的な違い

「関数（Function）」と「Skill」の決定的な違い
従来のプログラミングにおける関数は、入力に対する決定論的な変換器（Deterministic Transformer）です。

【従来の関数】 入力 (x) ──[ 厳格なアルゴリズム / 分岐 ]──> 常に同じ出力 (y)

一方で、学術論文『SoK: Agentic Skills』で定義されるSkillは、「手続き的記憶（Procedural Memory）」のパッケージングです 。単なるツールの呼び出しや関数の定義ではなく、以下の4要素の組（4-tuple）として形式化されています :

適用条件（Preconditions）: どんな状況・タスクのときにこのスキルを発動すべきか

方針・指針（Policy / Strategy）: 目標を達成するための思考プロセス、SOP（標準作業手順書）、ヒント

終了・成功判定条件（Termination Criteria）: 何をもって「完了」と見なすか

実行境界・ツール（Tool Interfaces）: 外部世界（シェルやAPI）に干渉できる手段

つまり、Skillとは

「決まったアルゴリズムの手順書」ではなく、「エージェントが自律的に状況を判断し、ゴールまで粘り強く試行錯誤するための行動規範・ポリシー」です 。

関数のように「1行目から順に固定された処理を走らせる」のではなく、「環境のフィードバックを見ながら目的を果たすための柔軟なガイドライン」を渡している点が根本的に異なります。

２. 「単発プロンプト」と「Skill開発」の違い

プロンプトエンジニアリングは通常、「その場（1ターン）でどう答えてほしいか」というコンテキストの注入です。

対してSkill開発は、ソフトウェア工学でいう「再利用性・合成性（Reusability & Composability）の獲得」です。

階層的合成: 1つのSkillが別の低レイヤーのSkillを呼び出したり、エージェントが必要に応じて動的に検索・ロードして自分の脳の拡張モジュールとして扱う。

自己改善と洗練: 失敗した実行ログ（軌跡）を振り返り、プロンプトやポリシーのダメな部分を蒸留・修正して、将来の汎用タスクでも使えるように資産化する。

「その場しのぎの対話プロンプト」から、「何度でも別コンテキストで使い回せる自律的な職人技（手続き的記憶）」へとパッケージングする作業こそがSkill開発です 。

３．「アジャイル・CI/CD」と何が違うのか？

「作って、試して、効果を見て、直す」というループはアジャイル開発と酷似しています。CI/CDでテストを自動化する発想も同じに見えます。

しかし、背後にある「不確実性の向き」が逆です。

従来のCI/CD・テスト:

前提: コードは書いた通りに動く（決定論的）。

目的: 人間が仕様の抜け漏れやロジックのミスをしていないかを、テストコード（assert文）で白黒判定する。

Skill開発のEvals（振る舞い評価ハーネス）:

前提: システム（LLM）自体が確率的であり、毎回同じ言葉や手順を踏むとは限らない 。

目的: 「同じ入力をしても、エージェントがゴールにたどり着く成功率が統計的に80%から95%に上がったか？」を測定する。

従来のテストが「バグの有無をゼロイチで検証する検品」だったのに対し、Skill開発の検証は「野生の動物（エージェント）に調教・訓練を施し、その習得度や行動傾向を測定する行動観察」に近い性質を持っています。

「Skill開発は、プログラミングなのか？」をここまで読んだ方は、本質を実感できるこの記事【ただのプロンプト」が「堅牢なSkill」だった】を是非ご覧ください。

  「ただのプロンプト」が「堅牢なSkill」だった｜AI活用で陥りがちな“見え方の錯覚”と再現性の本質 | AimanaVo

４．開発作法（エンジニアリング・プラクティス）の現在地

現在提唱されているSkill開発の作法は、驚くほど生々しい「職人芸と工学の境界」にあります。

過度な自己生成の罠（キュレーションの重要性）:

最新のベンチマーク（SkillsBenchなど）によると、AI自身に勝手に作らせたスキルは誤った思い込みや過剰適合を起こし、かえってエージェントの性能を下げることが分かっています 。人間が現場の勘所やドメイン知識を整理して手作業でキュレーションしたSkillこそが、最も高い性能を発揮します 。

失敗からの蒸留（Reflection & Distillation）:

エージェントがタスクを解こうとして失敗したとき、「なぜ失敗したのか」「どの前提が崩れていたのか」を記録し、それをSkillの「事前チェックリスト」や「エラー回復手順」として追加・更新していく作法が確立されつつあります。

なぜ「FORTRANの黎明期」に似ていると感じるのか

初期のプログラミングでは、高級なフレームワークも洗練されたIDEも型安全もありませんでした。「動かしてみたらメモリが溢れた」「止まった原因がわからない」という環境で、マシン（ハードウェア）の気まぐれな挙動と直接対話し、試行錯誤しながら論理を組んでいました。

LLMからの回答

※この回答は、私がFortranを言い出したために、その頃のたとえ話で説明してくれています。

いまSkill開発で起きているのも、「確率的で巨大なニューラルネットワークという未知の計算機」に対し、どう言葉と境界（ハーネス）を与えれば意図通りに動いてくれるのかを手探りで探る、まさに黎明期の体験そのものだからです。

LLMからの回答

「昔の概念の抽象化」ではなく、「決定論の世界から確率的エージェントの世界へ移行したことで、プログラミングという行為の前提が根本から組み直されている最中」なのだと言えます。