WATCH REPORT

WikiSkillとは。AIのスキルを成功と失敗の経験で育てる仕組みを、飯塚浩也さんが解説

2026.10.10

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん(@passion_tanaka)です。今回は、YouTubeチャンネル「飯塚浩也 | Obsidianでつくる最強の右腕」の『Googleが発表した「WikiSkill」これだけで今後のスキルの概念が変わります。【Cursor・Claude Code・Obsidian】』の動画を紹介するね。

AIに同じことを何度も伝えているのに、次の文章でもまた「意味が分からない」。その返事を、次に使える学びへ変えたいですよね。飯塚さんの動画「WikiSkill」は、記録を残す場所、学びをまとめる場所、AIが使う手順を置く場所を分ける考え方です。

私は、AIの文章に「分かりにくい」と返したやりとりを材料に、この流れを動かしました。大事なのは、学びをまとめて終わらず、そこから作った手順で文章が読みやすくなるかまで比べること。短くなった代わりに、必要な数字が消えていないかも確かめます。

第7章では、記録をそろえる、学びを作る、手順にする、書き直して比べる、という進め方をコピペ用の指示文と一緒にまとめました。採る条件は、結果を見る前に決めます。自分のAIとのやりとりを、次の書き方につなげるところから始めてみましょう。

SPEAKER

飯塚浩也 | Obsidianでつくる最強の右腕

出演: 飯塚浩也さん(チャンネル運営者)と、聞き役の男性。ホワイトボードで流れを描きながら、論文の図や自分の画面を見せて進めます。

動画: Googleが発表した「WikiSkill」これだけで今後のスキルの概念が変わります。【Cursor・Claude Code・Obsidian】

20分34秒、2026年10月5日の公開です。

この記事の軸は「成功も失敗も、スキルとは別の置き場に重ねる。AIが書くのは記録と仮説まで。採否と違和感の確認は人が持つ」。

3行でわかるポイント

  1. WikiSkillは、スキルと実行ログの間にWiki層を置く。成功と失敗を知識として残し、次の改善につなげる設計です。(第1章へ、第2章へ)
  2. 記録を貯めても、改善を正しく選べるとは限らない。私の自動改善の試験でも、同じスキルの評価が揺れていました。(第3章へ、第4章へ)
  3. WikiSkillを動かす手順では、採る条件を結果を見る前に決め、学習に使わない文章を2系統の判定役に読ませて効き目を確かめます。(第5章へ、第6章へ、第7章へ)

AIの「今」を毎日シェアしてる無料コミュニティやってます

GPTs研究会に参加する(無料・8,900名突破!)
01

「自転車の練習」のたとえ。失敗を一行足す直し方では、同じ指摘が戻る

▲目次
スキルに一行ずつ足す形と、別の置き場の記録を次の実行で読む形を左右に並べた図解
動画キャプチャ: 自転車の絵と「70点」「72」の書き込み、学びの吹き出しが映る場面(5:45頃)
動画キャプチャ: 自転車の絵と「70点」「72」の書き込み、学びの吹き出しが映る場面(5:45頃)

飯塚さんは、自転車の練習を例に、学びが次へつながらない問題を説明します。転んだらスキルに「ハンドルは離さない」と一行足す。WikiSkillは、その手順と実行ログの間に、成功も失敗も残すWiki層を置きます。

飯塚さん(動画の中で・3:09〜)

私娘と自転車の練習よくやってるんですね

飯塚さん(動画の中で・5:23〜)

失敗も成功も知識として学んできたのに次また練習する時にそれが生かされてない

私ならこうする。指摘を残す時に、次の仕事をするAIが読む場所まで確かめます。

AIエージェントに60点のままスキルを作らせない記事に、こう書きました。「作り方が決まる前に作らない」。このルールで、私は3月17日から9月27日まで、同じ種類の指摘を7回しました。

3月17日、AIへの返事は「決めてないよね。まだ。止めて。」でした。作り方を決める前に進めない。そのことを伝えたのに、9月27日にも「わからないならやる前にきけよ」と返しています。

注意書きはメモリにありました。でも、毎回読まれる場所にはなかった。ルールの記録には、それがくり返した理由として残っています。保存されていることと、次の仕事で読まれることは別だったんです。

私が同じ注意を言い直すたびに、任せた仕事の管理が私へ戻ってくる。約束を覚えるところまで委ねたいのに、その都度、私が止めていました。

飯塚さんは、自転車の練習のたとえで、失敗も成功も次に生かされない様子を話しています。私の場合は、残した注意が次の実行へ届くかが課題でした。学びを置くWikiにも、次にどこから読むかまでつなげたいですね。

→ 読む場所を確かめる

5分で、くり返した指摘を1件選び、保存先とAIが実行前に読むファイルを見比べてください。読む場所が見つからなければそこで止め、見つからなかったことを記録します。

02

「別のファイルに分ける」。WikiSkillは成功も失敗も別の置き場へ重ねる

▲目次
短いスキルと、ログと、失敗パターンを分け、失敗パターンからスキルの更新へ戻る流れを示した図解
動画キャプチャ: ホワイトボードに「Skills/」と「Raw/」の箱を書き、ログを残していると説明する場面(6:50頃)
動画キャプチャ: ホワイトボードに「Skills/」と「Raw/」の箱を書き、ログを残していると説明する場面(6:50頃)

失敗するたびに理由や経緯をスキルへ書き足すと、手順のファイルが膨らんでいきます。飯塚さんが説明するのは、成功と失敗を別のフォルダやファイルへ分ける方法。学びを残しながら、実行する手順をシンプルに保ちます。

飯塚さん(動画の中で・6:07〜)

しっかりとこの失敗したことうまくいったことを別のフォルダーとか別のファイルに分けてあげることでこのスキル自体はシンプルに保つことができると、ま、そういうメリットもあるんですね。

私ならこうする。手順と履歴を別のファイルに分け、履歴は上書きせず重ねます。

次の仕事で読む手順には、今使う内容を置く。一方、過去に何が起き、なぜ変えたかは別に残す。古い記録を消して短くすると、判断の経緯まで見えなくなるからです。

入口の大きさは、測らないと分かりません。

Cognition「Agent Memory Repo」を解説した記事では、AI秘書の凛ちゃんにMEMORY.mdの大きさを測ってもらいました。冒頭には「核心のみ常時ロード」「目安24KB以下」。10月7日の実測は33,157バイトで、目安を超えていました。

短くする方針は書いてあったんです。それでも、短く保てていなかった。方針と、実際のファイルの大きさは別に確かめる必要があります。

動画はスキル本体の肥大化を扱い、私が測ってもらったのは記憶の入口ファイルです。対象は違っても、読み出す場所へ何を置くかという問いは重なります。入口は核心に絞る。経緯は別に残し、必要な時に辿れるようにします。

→ 入口の大きさを見る

5分で、AIが最初に読むファイルの大きさと内容を見て、別に残す候補を1件選んでください。手順と過去の記録を分ける根拠が見つからなければ、移さずに止めます。

03

「観測して提案する」。ログを分析する役と、提案する役と、採るか決める人

▲目次
ログを観測し、直し案を提案し、採るかどうかは人が決める流れを示した図解
動画キャプチャ: ホワイトボードの「Raw/」「Wiki/」の箱と「失敗パターン」の書き込みが大きく映る場面(7:50頃)
動画キャプチャ: ホワイトボードの「Raw/」「Wiki/」の箱と「失敗パターン」の書き込みが大きく映る場面(7:50頃)

実行した記録を、別のAIが週1回分析する。同じミス4件からパターンを見つけ、さらに別のAIが改善を提案します。飯塚さんか別のAIが評価してから更新する流れです。記録を見る仕事と、直し方を考える仕事が分かれています。

飯塚さん(動画の中で・7:22〜)

そのAIエージェントが何をするかって言うと、ログを分析します。

飯塚さん(動画の中で・8:05〜)

観測をして提案をするというエージェントになります。

私ならこうする。分析と改善案づくりをAIへ任せ、採否を私へ渡すところまでの責任者を1人に決めます。

AIを増やしても、「次は誰がやる?」を私が毎回考えるなら、管理は減りません。分析した人、提案した人がいても、仕事全体を最後まで持つ人は1人。その人が次の工程と期限を覚え、判断材料を揃える形にします。

渡してほしいのは、ログの山だけではないんです。何を変えるか、根拠は何かまで考えた答え。

スキルを60点のまま作らせない記事には、セッション履歴を毎日蒸留し、意味検索に使えるようにする処理が記されています。AIの割り当ての実績を振り返り、ルールの改善案を出す処理も週1回あります。

履歴を見る仕組みは、私の環境にもある。ただ、履歴をもとにルール本文を直すところは、いまも私の手です。

飯塚さんの説明はスキル更新までをつなぐ設計です。私の運用では、ルール本文を直す所は人が担っています。この違いを見て、私は「分析できた」で仕事を終えず、採るか決められる形までAIに運んでもらいます。

→ 引き渡し先を決める

10分で、記録・分析・改善案・採否の担当と、全体の責任者1人を書き出し、判断材料を揃えます。担当が決まらない仕事があれば、実行を始めずそこで止めます。

04

「嫉妬するぐらい綺麗な設計」。経験をパターンにするから、学びになる

▲目次
散らばった失敗の付箋を集めて、1枚のパターンと学びにする流れを示した図解
動画キャプチャ: 論文の図で、Wikiの層とスキルの層が分かれて描かれている場面(11:40頃)
動画キャプチャ: 論文の図で、Wikiの層とスキルの層が分かれて描かれている場面(11:40頃)

飯塚さんは、実務に近いタスクでの改善効果と、失敗をパターンにする働きを紹介します。論文の表では、Gemini-3.5-FlashのSpreadSheetが50.5%から76.6%へ改善。役割を分けた設計を「嫉妬するぐらい綺麗」と評しています。

飯塚さん(動画の中で・9:46〜)

そういう私たちの実務に近いようなタスクでこのスキルの改善効果が1番高かったです

飯塚さん(動画の中で・10:49〜)

教訓になるようなこと、失敗したことをパターン化して、このパターン化するからこそ学びになるわけですよね。

飯塚さん(動画の中で・11:01〜)

嫉妬するぐらい綺麗な設計ですね。

私ならこうする。元の記録を残しながら、次の同じ場面で判断を変えられる教訓にまとめます。

学ぶたびに、毎回読む内容が増えていく。それでは改善のための確認が仕事を圧迫します。出来事を詳しく残す場所と、次に使う教訓を読む場所は分けたいんです。

WikiSkillの論文の表では、Gemini-3.5-FlashのLiveMathが、スキル無しの33.0%から72.6%へ、SpreadSheetが50.5%から76.6%へ改善しています。Qwen-3.6-27BのALFWorldは52.8%から77.6%です。

一方、私の手元で数えたのは、事故のあとに直したルールです。事故の日付と私が言った原文を、AIが読む場所へ書き込んできました。15項目、文書は11本。人の手で、その都度直してきた記録です。

この15項目から、似た事故に共通する条件は見つかるかな。次に同じ状況になった時、何を変えればいいかな。そこを一文にして、元の記録もたどれるように残す。保存した数から一歩進んで、次の判断に使える形へ育てたいですね。

→ 繰り返しをまとめる

10分で、似た失敗2件の共通条件と次に変える判断を一文にし、元の記録を両方たどれるようにします。共通条件が確認できなければ、無理にまとめずそこで止めます。

05

「この後組む予定」。設計の説明と、評価の物差しが揺れた私の試験

▲目次
記録、提案、評価の流れと、目盛りがずれて揺れる評価の物差しを左右に並べた図解
動画キャプチャ: 論文の登場人物を自分の環境に当てはめた表(Wiki MaintainerやSkill Proposerなど)が映る場面(15:10頃)
動画キャプチャ: 論文の登場人物を自分の環境に当てはめた表(Wiki MaintainerやSkill Proposerなど)が映る場面(15:10頃)

手順を置くskills/と、学びを置くwiki/。記録を整理するWiki Maintainerと、改善案を作るSkill Proposerも説明されます。飯塚さんは「この後組む予定」と話しており、動画で示されるのは設計と更新の流れです。

飯塚さん(動画の中で・15:03〜)

これはですね、この後組む予定であるんですが

飯塚さん(動画の中で・15:47〜)

この2つを作って毎回自動実行させればあとは私が承認するとこのスキルがアップデートするという仕組みですね。

私ならこうする。改善前後を比べる前に、同じものを測って同じ判断ができるかを確かめます。

10月6日に、スキル改善ループへ「判定のブレを測り、測れなければ保留を返す」という仕組みが入りました。

AI秘書の凛ちゃんが試しに回したのは2ラウンド。使ったトークンは3,040,018と2,835,686でした。そこまで回しても、直しを採る判断にはつながらず、どちらも元に戻しています。

評価用に見せない2本で、直す前の同じブログ用スキルを測ると、16.7点と0点に割れました。変更する前の同じものなのに、点が違う。これでは、修正後に点が上がっても、修正が効いたのか、測るたびに揺れているのかを見分けられないんです。

見分けるには1束およそ40本が要る。だから、処理をたくさん回したことだけで「よくなった」と決めず、測れない時は採否を保留します。

飯塚さんは動画で「この後組む予定」と話しています。第7章には、動かした手順をコピペで使える形にまとめました。まずは改善を採る根拠を確かめること。本番に入れた3件の効果は、次の動画ブログの味見で分かります。AIには、その結果まで確かめてもらいたいですね。

→ 物差しの揺れを調べる

15分で、変更していない同じ出力を同じ基準で再評価し、結果の揺れを確かめてください。揺れを見分ける根拠が揃わなければ比較を止め、改善案の採否を保留します。

06

「自分の環境に応用して初めて意味がある」。論文は自分の言葉で持ち帰る

▲目次
論文、自分の環境、自分の言葉の順に持ち帰り、採否の札を自分で持つことを示した図解
動画キャプチャ: エディタのフォルダ画面で、memoriesの中のcorrectionsを指す場面(13:20頃)
動画キャプチャ: エディタのフォルダ画面で、memoriesの中のcorrectionsを指す場面(13:20頃)

まとめで飯塚さんは、スキルと知識が分かれている設計を挙げます。モデルが変わっても、Wikiの知識は引き継げる。アフタートークでは、論文を自分の環境へ応用し、自分の解釈を加えて言葉にすることを話しています。

飯塚さん(動画の中で・17:47〜)

設計の美しいところはスキルと知識がしっかり分れてることですね。

飯塚さん(動画の中で・19:14〜)

橋渡しですよね。やっぱり論文って自分の環境に応用できて初めて意味があると思ってんですよね。

飯塚さん(動画の中で・19:51〜)

論文は外部情報ですよね。なんでそこを読んで自分がどう思ったか解釈を加えて自分の言葉でまとめる

私ならこうする。AIが書く記録と仮説を分け、採るかの評価と、自分に引っかかる所がないかの確認は私が持ちます。

筋の通った説明でも、自分の出来事が別の話へ変わっていたら採れません。言葉が整っていることと、私の出来事に合うこと。その両方を見たい。

入口ファイルを短く保つ話を書いた記事では、AIが補った日付や出典をそのまま信じず、私が実際に言った言葉と見比べると書きました。件数や割合も、自分の記録へ戻って確かめます。

過去に起きた事実、その時の感情や解釈、いまの私の再解釈。それぞれ別の行に残す。今の考えが深まっても、当時の出来事や気持ちを上書きしません。

私が自分の環境へ持ち帰るのは、AIへ書かせる行の境界です。記録の整理と仮説は任せる。本人の言葉や事実として残す行は照合する。そのうえで、自分が語って違和感のない表現かを確かめます。

→ 書ける行を分ける

10分で、最近のAIの記録1件の事実と仮説を分け、日付・出典・本人の言葉を原文と照合します。原文を確認できなければそこで止め、合わない行は事実として残しません。

07

WikiSkillを自分のAIで動かす。記録から手順を作り、採るかを先に決める

▲目次
記録、学び、手順、検証、採るか戻すかの5つの場面を左から右へ並べ、自分の記録で最後まで動かして確かめる流れを示した図解
動画キャプチャ: ホワイトボードにSkills、Raw、Wikiの箱と失敗パターンが描かれ、「流れとしてはそんなに難しくない」と字幕が出る場面(8:50頃)
動画キャプチャ: ホワイトボードにSkills、Raw、Wikiの箱と失敗パターンが描かれ、「流れとしてはそんなに難しくない」と字幕が出る場面(8:50頃)

論文は、自分の環境に応用して初めて意味がある。飯塚さんが「流れとしてはそんなに難しくないですよね」と話したWikiSkillも、動かしてみたいですよね。ここでは、自分のAIとのやりとりから学びと手順を作り、効き目を比べる方法をまとめました。

飯塚さん(動画の中で・8:50〜)

流れとしてはそんなに難しくないですよね。複数のファイルを使ってなんか管理してる感じに変わったのかなって気がします。

作るもの:記録・学び・手順の3つ

作るものは3つ。最初が記録で、次が学び、最後が手順です。記録は、AIが出した文章と、私が「分かりにくい」「意味わからない」と返した返事の組。学びは、どの書き方が伝わらなかったのかをまとめたページ。手順は、その学びを文章を書くAIが使える形にした指示です。私は42件の組を材料に、AI秘書の凛ちゃんが動かしたこの方法を試しました。書き直す役は手元のGemma 4・31B。学びと手順を作る役はGPT系のAIで、読み比べはGPT系とClaudeの2系統に頼みました。

WikiSkillを自分のAIで動かす5つの手順の図。記録をそろえ、学びを作り、手順を書く。採る条件を結果の前に決め、書き直して2系統の判定役で比べる。記録は学習用と検証用と確認用に分ける
WikiSkillを自分のAIで動かす5つの手順の図。記録をそろえ、学びを作り、手順を書く。採る条件を結果の前に決め、書き直して2系統の判定役で比べる。記録は学習用と検証用と確認用に分ける

手順1:記録をそろえて、用途ごとに分ける

まず、AIが出した文章と、それに「分からない」と返した自分の返事を、組にして集めます。「分からない」の一言だけでは、どこを直せばよいか分かりません。元の文章と返事を並べ、対応する番号を付けましょう。集めた組は、古い方を学習用に、残りを検証用と最後の確認用に分けます。学習用は学びを作る材料、検証用は手順を直すための比較、確認用は最後の採否に使います。私は、学習用27件と検証用6件に分け、確認用は42件とは別に集めた12件にしました。確認用は手順を直す時には見せず、手順を固定してから最後に1回だけ使います。学習で一度読んだ文章では、初めて見る文章への効き目を測れないので、同じ組を使い回さないことが大事です。

手順2:学びを作る

次に、学習用の文章と返事をAIに読ませ、「どんな書き方が、分からないと言わせたのか」をまとめてもらいます。似た指摘はまとめ、最大8パターンに絞ります。各パターンには、読んで何が分からなくなるかという症状、元の言い回しを引用した原因、どう書き換えるかという直し方、根拠にした組の番号を残します。「もっと具体的に」の一言では、次のAIも迷います。どの表現を、何が起きたと分かる文章へ変えるのかまで書いたページが、学びを残す「wiki」です。下の指示文をそのまま貼って使えます。

① 学びをまとめる役への指示文

あなたは学びをまとめる役です。次は、AIが出した文章と、それを読んだ私の返事(分かりにくいという文句)の組です。
「どんな書き方が、私に分からないと言わせたか」を、繰り返し出ているパターンごとに、学びのページにまとめてください。
各パターンは、症状(返事の言葉)・原因(元の文のどこがそうなっているか。実際の言い回しを引く)・直し方・根拠の番号を書く。
最大8パターン。出力はMarkdownだけ。

(ここに、学習用の組を貼る:文章の本文と、私の返事の原文)

手順3:手順を書く

学びのページができたら、それを別のAIに読ませ、文章を書くAI向けの手順を1300字以内にまとめてもらいます。ここでは「読みやすく書く」という目標だけで終わらせず、してはいけない書き方と、代わりにどう書くかを具体的に並べます。元の事実や数字、判断に必要な情報を削らないことも入れましょう。書き直すAIへ渡すのは、この手順だけ。学びのページは見せません。学びを読み込まなくても、手順だけで書き方が変わるかを確かめるためです。下の指示文をそのまま貼って使えます。

② 手順を書く役への指示文

あなたは手順を書く役です。下の学びのページを読み、AIが文章を書く時の手順を、1300字以内で書いてください。
書く役のAIは、この手順しか読めません(学びのページは読めません)。
してはいけない書き方と、代わりの書き方を、具体的に並べてください。元の事実・数字・判断材料を削らないことも手順に入れてください。出力は手順の本文だけ。

(ここに、学びのページを貼る)

手順4:採る条件を、結果を見る前に決める

採る条件は、結果を見る前に紙へ書いて固定します。私が使ったのは3つ。両方の判定役で、今ある決まりより読みやすいとされた件数が、そうでない件数より多いこと。元の文にない作業用語が新しく出た回数が、今ある決まりより多くないこと。元の数字が残る割合が、今ある決まりより5ポイント以上低くないことです。満たさなければ今ある決まりへ戻し、負けた理由を学びに足して手順を直します。直して比べる回数も、最大4回までと先に決めましょう。下の指示文をそのまま貼って使えます。

③ 採否の決まり(結果を見る前に紙に書いて固定する)

比べる相手は「今ある決まり」。確認用の文章で、新しい手順がそれより良いかを判定し、次の3つを全部満たした時だけ採用する。
1. 2系統の判定役のそれぞれで、新しい手順が勝った件数が、負けた件数より多い。
2. 元の文に無いのに書き直しに新しく出た作業用語の数が、今ある決まり以下。
3. 元の文の数字のうち書き直しにも残った割合(件ごとに出して平均)が、今ある決まりより5ポイント以上低くない。
検証用の文章で満たさなかった時は、負けた理由を学びに足して手順を直し、検証用で比べ直す(直すのは最大4回)。
確認用の文章で満たさなかった時は、その手順は不採用にして今ある決まりのままにし、そこで終える。
確認用の文章は、手順を直す時には見せず、手順を固定してから最後に1回だけ使う。

手順5:書き直させて、2系統の判定役で比べる

同じ元の文章を、「新しい手順あり」「今ある決まりのまま」「手順なし」の3条件で書き直してもらいます。どの条件でも、事実・数字・選択肢を変えたり足したりしないよう伝えます。できた文章は条件名を伏せ、書き直したAIとは別の判定役に読み比べてもらいましょう。私はGPT系とClaudeの2系統を使いました。同じ比較でも、GPT系は9件のうち4勝4敗1引き分け、Claudeは7勝1敗1引き分けだったからです。一つの判定だけで決めず、両方の結果を見ます。下の指示文をそのまま貼って使えます。

④ 書き直す役への指示文(手順あり・今ある決まり・手順なしを、同じ文面で比べる)

次は、私に送った文章です。私は読んで意味が分からないと返しました。
事実・数字・URL・選択肢は変えず、足さず、私が一度読んで分かる文章に書き直してください。出力は書き直した文章だけ。

<手順>(ここに貼るもの: 手順ありの条件→②の手順/今ある決まりの条件→その決まりの本文/手順なしの条件→この欄ごと消す)</手順>
<元の文章>(ここに元の文章を貼る)</元の文章>

(3つの条件で、同じ元の文章を1件ずつ書き直させ、どの条件の出力かを自分で記録しておく)

⑤ 読み比べをする判定役への指示文(GPT系とClaudeなど、2系統に別々に貼る)

項目ごとに、元の文章と、書き直し2つ(XとY)があります。
私が一度読んで、①何が起きたか絵が浮かぶ ②何を決めるのか分かる ③選ぶと何が起きるか分かる、のはどちらですか。
事実の抜けや足し込みが大きい方は不利にしてください。どちらの手順で書いたかは分かりません。
出力は、項目ごとにXかYか引き分けだけ。

<項目1>
<元の文章>(ここに貼る)</元の文章>
<X>(書き直しの1つ)</X>
<Y>(もう1つ)</Y>
</項目1>
(項目2以降も同じ形。XとYにどの条件を割り当てたかは件ごとに入れ替え、割り当てを自分で記録しておく)

⑥ 数字の残り割合と、新しい作業用語の数え方

【数字の残り割合】元の文の数字(半角の連続した数字)を全部取り出して重複をなくし、そのうち書き直しにも出てくるものの割合を、件ごとに出す。全件の平均が、その条件の数字の残り割合。
【新しい作業用語】読んで意味が分からない作業用語の一覧を、自分で先に作る(例: 通す・照合・台帳・ゲート)。件ごとに「書き直しでの出現回数 − 元の文での出現回数」(マイナスは0)を出して全件を足す。元の文に数字が1つも無い件は、数字の残り割合の平均から除く。

つまずきやすい4つ

気をつけたいのは、分かりやすくしようとして、判断に必要な情報まで削ってしまうことです。私が試したある1件では、タスクの番号、担当の番号、確認の番号などが消え、元の文にある数字のうち残った割合は約53%でした。短い文章になっても、どの仕事を誰が確認するのかを追えなくなれば困りますよね。文章の長さだけでなく、元の数字がどれだけ残ったかも測りましょう。もう一つは、学習した文章で効き目を確かめてしまうこと。学びを作る時に読ませた文章を、そのまま比較にも使うと、初めて見る文章に効くかが分かりません。学習用と検証用は別にし、最後の確認用も取っておきます。

言葉の数え方にも注意が必要です。専門的な言葉を全部数えると、書き直すAIが増やした言葉と、元の文から写した言葉が混ざります。実際、作業用語として数えた4回のうち2回は、元の文にもあった「差し込み」でした。採否で数えるのは、元にないのに新しく出た作業用語です。判定役も一つに絞りません。同じ9件を比べても、GPT系は4勝4敗1引き分け、Claudeは7勝1敗1引き分けでした。「読みやすい」の判断はAIによって違います。二つの判定結果を並べ、先に決めた条件を両方で満たすかを見ましょう。

1件の書き直しで元の情報が残ったかを比べた表。短く削った版は番号類を先に削り数字の残りは53%。今ある決まりは93%。数字を残す指示を足した版と照合まで入れた版は100%で、照合まで入れた版は1行目のタスク番号だけが消えた
1件の書き直しで元の情報が残ったかを比べた表。短く削った版は番号類を先に削り数字の残りは53%。今ある決まりは93%。数字を残す指示を足した版と照合まで入れた版は100%で、照合まで入れた版は1行目のタスク番号だけが消えた

実例:採用した手順と、その効き目

この方法で残った手順を、私は「C4」と呼んでいます。元の作業用語も具体的な出来事に言い換え、元の名前は必要な時だけ括弧で1回添える。判断材料は見出しで分けて残し、元の文と書き直しを双方から照合する手順です。42件とは別の、私が分かりにくいと返した12件で比べると、今ある決まりに対してGPT系は7勝5敗、Claudeは8勝4敗。新しい作業用語は両条件とも0回でした。元の数字が残った割合は、今ある決まりが約99%、C4が約95%。先に決めた3条件をすべて満たしました。手順の全文を下に載せました。

新しい確認用12件の読み比べ。手順C4は今ある決まりにGPT系で7勝5敗、Claudeで8勝4敗。元の文に無い新しい作業用語はどちらも0回。数字の残りはBが99%でC4が95%で、先に決めた条件をすべて満たした。手順C3はGPT系で8勝2敗2引き分け、Claudeで10勝2敗
新しい確認用12件の読み比べ。手順C4は今ある決まりにGPT系で7勝5敗、Claudeで8勝4敗。元の文に無い新しい作業用語はどちらも0回。数字の残りはBが99%でC4が95%で、先に決めた条件をすべて満たした。手順C3はGPT系で8勝2敗2引き分け、Claudeで10勝2敗

⑦ 実際に採用した手順C4(③の決まりを通った手順の全文。④の手順ありの条件に貼る。実験で使った文のうち、2か所だけ語を言い換えてある)

# Ask本文を書き直す手順C4

目的は、事実と判断材料を削らず、作業用語を知らない人にも「誰が・何を・どこで・どうした/どうなる」が伝わる本文にすること。元の各文を言い換えてから、見出しで整理する。

1. 使える事実は元文と明示された補足だけ。比較文や過去の書き直しから情報を足さない。途中で切れた文の続き、選択肢、かかる負担、確認結果を補わない。意味が不明な箇所は推測で埋めず、不明と分かる形で残す。

2. 各文の主語・対象・場所・日時・きっかけ・結果・確認範囲を保つ。送った、受け付けた、読んだ、採用したは別。未確認を未修正に、写真での確認を実際の操作確認に変えない。推測・見込み・未計測と、その対象を残す。

3. 最新の質問へ冒頭で直接答える。「おすすめはどれ」なら画像名と場所、「まとめはどこ」なら場所とURL、「目的は何」なら目的そのものを書く。答えをリンクだけに任せない。続いて今回選ぶことを一文で示す。前案を変えた場合は、前案・今回案・変更理由を残す。

4. 元文にある作業用語も、そのまま写さない。見出し・本文・選択肢・引用・リンクの説明まで、具体的な出来事へ言い換える。
「差し込み」→「『完了の確認を出してください』という指示が届く」
「検査に通す」→「記事のリンクを検査する」
「試験が通る」→「試験で期待した結果になった」
「照合」→「元の文章と1行ずつ比べ、一致するか確かめる」
「ゲート」→「条件を満たさない記事を止める仕組み」
「台帳」→「投稿日時と結果を記録した一覧」
例は文脈に合う場合だけ使う。比喩や別の専門語への置換で済ませず、誰に何が起きるかを書く。

5. 元の名前は、対象を見つけるために必要な場合だけ、普通の説明の後に括弧で1回添える。以後は説明した呼び方を使う。URL・ID・ファイル名・画面上の文字は正確に保ち、何を指すか添える。名前や引用を理由に、作業用語だけで説明しない。新しい専門語や独自の呼び名を作らない。

6. 判断材料は「現在」「変更後」「確認したこと」「かかる負担」「リスクと戻し方」「未決定」などの見出しで分ける。実例、内訳、担当、数字、日時、一回限り等の条件、変更しない範囲、例外、留保を残す。「など」や総数だけにまとめない。削るのは重複と冗長な言い回し。求められた全文をリンク先だけへ移さない。

7. 元の各選択肢に、対象・試作か実際の利用先の変更か・押した直後の結果・後で決めることを示す。待機を今すぐ本人に頼む作業へ変えない。根拠のない「最適」「解消」「安全」や新しい動きを足さない。URLには見る場所と比べる点を添え、本文・実物・選択肢の名前をそろえる。

8. 最後に元文と書き直しを双方向に読み比べ、欠落・追加・条件変更・矛盾を直す。さらに作業用語だけを探して読み直し、元文由来の語も言い換える。数字が残っていても、誰が何をするか分からなければ書き直す。

どこまで使えるか

使う目安は、手元のGemmaによる12件・各条件1回の書き直しです。勝ち数の差は小さく、判定もAIによるもの。12件には、縦長を横長にしてほしいなど、文章だけでは直せない指摘も含まれます。今ある決まりより読みやすいと判定された手順ですが、実際のAI秘書が読む決まりには入れておらず、私の文句が減るかは測っていません。別の16本で同種の文句を数えた前28件・後24件も、減ったとは言えませんでした。飯塚さんの「この後組む予定」という流れを、自分のAIでも小さく動かして、数字を測ってみましょう。

→ 最初の組を集めよう

まず15分、自分がAIに「分からない」と返したやりとりを探し、元の文章と返事を並べましょう。どの文章への返事か確かめられないものは、学びを作る材料に入れず止めます。

FAQ

よくある質問

▲目次

Q. WikiSkillは、スキルに失敗を書き足す方法と何が違う?

A. 学びを残す場所が違います。手順を置くスキルと、成功・失敗から得た知識を置くWikiを分ける。実行ログからパターンを見つけ、その知識とログ、スキルを見て改善案を作る流れです。私なら、元の履歴も消さずに残します。

Q. 自分の環境でWikiSkillの考え方を試すには、まず何から始める?

A. まず、AIが読む手順を置く所と、仕事から得た学びを置く所を分けます。成功と失敗も別に残し、元の記録は消さず、学びからたどれるようにします。そこから改善案を作り、採るかどうかは人が決める形で始めましょう。

Q. AIが改善案を出したら、そのまま採ってよい?

A. まず、何を根拠に、どこを変える案なのかを確かめたいですね。変更していない同じ出力を同じ基準で再評価し、その物差しで改善前後を見分けられるかを確認します。結果が揺れて判断できなければ採否を保留し、元の記録と変更前の状態を残して、人が決めます。

Q. 論文の数字、たとえば33.0%から72.6%は、どこで確かめられる?

A. arXivの論文2608.27454の表で確かめられます。LiveMathの33.0%から72.6%、SpreadSheetの50.5%から76.6%はGemini-3.5-Flash、ALFWorldの52.8%から77.6%はQwen-3.6-27Bでの結果です。

Q. WikiSkillの流れを、自分のAIで動かすには何から始める?

A. まず、使っているAIとのやりとりから、「分からない」と返した文章と返事を組にして集めます。学習用と検証用に分け、学習用から学びをまとめ、文章を書くAI向けの手順にします。比較結果を見る前に、その手順を採る条件を決めましょう。

MATOME

まとめ。学びを残す場所と、改善を選ぶ責任を分ける

▲目次

学びを残す場所と、改善を選ぶ責任を分ける。成功も失敗も、それぞれの記録として重ね、AIには記録の整理から改善の仮説まで運んでもらいます。第7章の手順では、採る条件を結果を見る前に決めます。

新しい手順ができたら、根拠を確かめ、今ある決まりと同じ物差しで比べる。数字や判断材料が残っているか、私が語って違和感がないかも見る。学びをためるだけでなく、次に使える形へ育てていきたいですね。

COLUMN

失敗ノートは別冊にして、直すかどうかは自分で決める

ひろくんが分厚くなったレシピ本とは別に、失敗ノートの別冊を開いて、直すかどうかを自分で決める料理のたとえの図解

レシピ本の余白へ、失敗するたびに書き足すとします。「火が強かった」「ここで混ぜすぎた」「この順番ならうまくいった」。次に作る時、本を開いても、今日使う手順を探すところから始まる。料理のたとえで考えると、失敗を書き足し続けるほど本は厚くなります。私なら失敗ノートを別冊にする。成功した条件もそちらへ残します。レシピ本には今使う手順を置き、別冊を読んで直すかどうかは自分で決める。その形なら、過去の味も消さずに残せます。

別冊をAIへ渡したら、私は何をするのか。そこを曖昧にしたくないんです。「あとはお願いします」と渡したあとで、進み具合を思い出し、次の仕事を指示し、抜けたところを埋めるなら、手放した仕事が別の姿で戻ってきます。私が任せたいのは、約束を覚えて最後まで運ぶ責任も含む。記録を整理して終わるなら整理の仕事、改善案まで出すならその仕事。どこまで持つのかを決め、その範囲を1人がやり切る。私は必要な判断に向き合えるようにしたい。

ただ、私にも手放せないところがあります。結果を自分で所有し、自分の手で完成させなければと執着した時、仕事を持ったままになる。今もこの戦いの最中です。よくしたい気持ちがあるからこそ、任せたあとも自分で仕上げたくなる。ここで「人が確認する」を広げすぎると、全部を私が触る理由にもなるんです。私が持つ確認は何か。任せた人が持つ責任は何か。その境目を、その仕事の目的に戻って決める。委ねるOSは、私の弱さも含めて考えるものです。

「測れないので採らない」という答えも、私は受け取れる形にしておきたい。改善案が出るたび採用しなければ、仕組みが進んでいないように見える。でも、評価が揺れたまま変更を重ねたら、何が効いたのか分からなくなります。私がGOを出した自動改善では、AI秘書の凛ちゃんが回した2ラウンドとも修正を戻しました。その結果を、失敗したから隠す話にはしない。見分けられなかった事実を残す。次に何を確かめる必要があるかまで、判断材料になるからです。

別冊の失敗ノートを育てる目的は、本棚をいっぱいにすることではありません。次の料理で、必要な一頁を開けること。仕事でも、私が同じ注意を言い直さずに済み、任せた人が根拠を持って動けるところへつなげたい。その先で私が何を味わい、何に夢中になるかは、自分で選びます。抱え込みOSから委ねるOSへ。私の判断軸を込めながら、実行と整理は任せる。全部を自分の手で完成させる癖と向き合い、自分が持つ一手を選んでいきます。

任せたあとに拾い切る話は、分身AI.comの日記にも書いています。「AI秘書が気づいた214件、拾われて初めて「委ねる」は完成する話」

分身AIについてもっと知りたい方は分身AI.comもチェックしてね!

LINK

関連記事

REF

参考リンク

今回紹介した動画

タイトルGoogleが発表した「WikiSkill」これだけで今後のスキルの概念が変わります。【Cursor・Claude Code・Obsidian】
チャンネル飯塚浩也 | Obsidianでつくる最強の右腕
公開日2026年10月5日
長さ20分34秒
URLhttps://www.youtube.com/watch?v=MklukYFHn3E

🎁 無料プレゼント

Aiport(ClaudeCode AIエージェント実践会)

ClaudeCodeでAI秘書+分身AI+AIカンパニーが無料で作れるキット&解説動画をプレゼント!

▶ 無料で入会してキットを受け取る

🤖 AI生成コンテンツについて

この記事はAIツール(Claude Code)を活用して制作しています。構成・文章生成にAIを使用し、最終的な内容の確認・編集・公開判断はひろくん(田中啓之)本人が行っています。「分身AIひろくん」(bunshin-ai.com)とは別のコンテンツです。

この記事が気に入ったら、シェアをお願いします

この記事で学んだことを誰かに教えて恩送りして学びを深めよう!

XLINEはてブ

関連記事