AIエージェント向けのSkillは、たいてい「作業を速く終わらせる」ために作られる。テストを書く、リファクタする、調べてまとめる——エージェントが人間の代わりに手を動かす方向だ。oi-owarasero はその逆を向いている。意図的に作業を引き取らず、問いだけを返すSkillである。

oi-owaraseroが使う5ステップの地図。決めろ(終わりが見えていない)→分けろ(動ける粒度になっていない)→始めろ(開始の摩擦が大きい)→出せ(評価への怖さで抱えている)→回せ(経験が次に変換されていない)
SKILL.md が「詰まりの見立て」に使う5ステップと、それぞれが疑う原因。チェックリストではなく、次の問いを選ぶための地図として使われる

この記事のポイント

書籍由来の実在プロジェクト。ダイヤモンド社刊『おい、とりあえず終わらせろ』(ISBN 9784478124192)の5ステップを対話手順へ再構成したもので、国立国会図書館サーチのAPIで書誌を確認済み
中身はSKILL.md 1枚(231行)。スクリプトもツールも持たず、エージェントの振る舞いを言葉だけで規定する
Claude Code / Codex 両対応は実際に成立。skills CLI 1.5.23 で導入し、汎用パスの実体+Claude Code へのシンボリックリンクをファイル単位で確認した

Skill というフォーマット自体や CLAUDE.md との使い分けは Claude Code|2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめてあるので、前提が曖昧なら先にそちらを見てほしい。

検証環境は macOS 14(Darwin 23.5.0)/ Apple Silicon、skills CLI 1.5.23、Claude Code 2.1.241。ユーザー環境を汚さないよう、独立した HOME を切って導入を試している。

oi-owaraseroとは——「終わらせない自分」を構造から見る対話Skill

nwiizo/oi-owarasero は、2026-08-25 に公開された Agent Skill だ。GitHub APIで実測した数値は、★52・fork 0・オープンIssue 0・MITライセンス・最終push 2026-08-31。topics には agent-skills / claude-code / codex / japanese / productivity が設定されている。

リポジトリの中身は驚くほど小さい。ファイルはたった4つである。

パス 役割
skills/oi-owarasero/SKILL.md 本体。231行・14,904バイト
assets/oi-owarasero-cover.jpg 書籍の表紙画像
README.md 導入と使い方
LICENSE MIT

実行可能なコードは1行も無い。このSkillの実体は、エージェントに与える日本語の指示文そのものだ。Agent Skill という形式が「プロンプトをパッケージとして配布する」ものである以上これは正しい姿だが、スクリプトやMCPサーバーを同梱するSkillが増えているなかでは珍しい部類に入る。

書籍をエージェントのSkillへ変換するというアプローチ自体は前例があり、当サイトでも book-to-skill解説|技術書を Claude Code スキルに変換する仕組みと落とし穴 で扱った。ただしあちらがPDFから機械的にSkillを生成するのに対し、oi-owarasero は著者本人が手で書き下ろしている点が違う。

土台になっているのは書籍である。国立国会図書館サーチのAPIで ISBN を引くと、おい、とりあえず終わらせろ : そうすれば「動けない自分」が変わるから(ダイヤモンド社)が1件ヒットする。著者はリポジトリのオーナーと同じ nwiizo 氏で、自著の方法論を自分でSkill化したという構図だ。リポジトリ側は「書籍本文の代わりになる要約や、本文・図版の転載物ではありません」と明記しており、実際 SKILL.md に書籍からの引用は無く、5ステップの名前と考え方だけを借りている。

もう一つ、リポジトリ構成として珍しいのは skills/oi-owarasero/ という入れ子のディレクトリを切っている点だ。SKILL.md をリポジトリ直下に置く配布物も多いなか、この形にしておくと1つのリポジトリで複数のSkillを配れるうえ、skills CLI 側で --skill oi-owarasero と名前を指定して取り出せる。README が「共通のAgent Skills形式を採用し、ツールごとに内容を複製しません」と書いているとおり、Claude Code 用と Codex 用に同じ内容を2つ置く、という重複を避けた構成になっている。実際に導入した結果(後述)もこの主張と一致していた。

SKILL.md は何を書いているのか——5ステップという「地図」

SKILL.md の構成を見ると、これが単なるプロンプト集ではないことがわかる。中核は「5ステップで詰まりを見立てる」節で、決めろ / 分けろ / 始めろ / 出せ / 回せ のそれぞれに「疑う原因」と「問いの例」が対応づけられている。

ステップ 疑う原因 SKILL.md に書かれた問いの例
決めろ 終わりが見えていない 「誰が、これを受け取ったあとに何をできれば、今回は十分でしょう?」
分けろ 動ける粒度になっていない 「今の自分が一度で終えられる動ける粒度まで縮めると、何が残りますか?」
始めろ 開始の摩擦が大きい 「次に始める瞬間、最初に手を動かす一動作は何ですか?」
出せ 評価への怖さで抱えている 「途中の問いを60点として出すなら、誰に何を一つ確かめたいですか?」
回せ 経験が次に変換されていない 「同じ場面がもう一度来たら、次は何を一つ変えて試しますか?」

重要なのは、SKILL.md がこの5つを順番に埋めさせることを明確に禁じている点だ。「5ステップは、ユーザーに全項目を答えさせるチェックリストではない。対話相手が次の問いを選ぶための地図として使う」「順番を固定しない」「すでに話された内容は飛ばし、地図上でいま扱える問いだけを使う」と書かれている。LLMにフレームワークを渡すと機械的な穴埋めインタビューになりがちで、そこを明示的に潰しにいっている。

質問の出し方にも制約がある。1ラウンド最大3問、しかも「ある問いの答えで内容が変わる問いは、同じラウンドに入れない」——依存関係のある問いを同時に投げない、という指定だ。さらに「感情が強い場面、答えにくい話題、本人が短く答えているときは一問だけにする」と、負荷に応じて問い数を落とす条件まで書いてある。

もう一つ目を引くのが「60点を下げてはいけない領域」という節である。この本の核は「60点で出せ」だが、SKILL.md はその例外を明示する。

安全性、セキュリティ、個人情報、アクセシビリティ、データ消失防止、必要な事実確認は、速く動くために省かない。

そのうえで「公開、送金、削除、本番反映など後戻りしにくい行為では、60点の範囲を下書き、プレビュー、検証、実行を判断する人への事前確認までに置く。実行そのものは含めない」と続く。エージェントに「60点でいいから早く出せ」と教えると危険な方向へ倒れうるところに、先回りしてガードを置いている。Skillとして配布する以上、方法論をそのまま渡すと事故るという認識が設計に入っている。

対話は5つの段階を通る——ただし順番は固定しない

SKILL.md は対話の流れを5段階で定義している。ここも「順番を固定しない。すでに話された内容は飛ばし、地図上でいま扱える問いだけを使う」という前提つきだ。

flowchart TD S1["1. 一場面に戻る
抽象的な自己評価を
具体的な一場面へ"] --> S2["2. 感情と構造を分ける
感情を消さず
事実だけを取り出す"] S2 --> S3["3. 反省を省察へ変える
「誰が悪いか」でなく
「何が見えていなかったか」"] S3 --> S4["4. 5ステップで見立てる
決めろ/分けろ/始めろ
/出せ/回せ"] S4 --> S5["5. 次の一周を本人が選ぶ
変えることを一つだけ"] S5 -.->|"動いて得た情報を持って戻る"| S1

段階1の「一場面に戻る」は、抽象的な自己評価を具体へ引き戻す工程だ。「いつも先延ばしする」のような発言が出たら「否定せず、『いちばん最近それが起きたのは、どんな場面でしたか』と具体へ戻す」と指示されている。主語が「いつもの自分」のままだと構造が見えないので、単一の場面まで降ろす。

段階2「感情と構造を分ける」には、安全側に倒す条件が入っている。「つらさが強い場合は、休憩や相談を次の行動にしてよい。体調や安全の問題を、行動力だけの話に縮めない」。生産性の文脈に health の問題を巻き込まないための線引きで、この種のSkillとしては重要な配慮だ。

段階3「反省を省察へ変える」が、このSkillの名前どおりの中核になる。「『努力不足』『確認不足』のような答えで止めない」「本人を追い詰めない範囲で、『誰が同じ状況にいても起こりうる要因はありますか』と構造へ視点を広げる」。個人の資質の話を、再現しうる構造の話へ移す操作である。

段階5まで来ても、5ステップは直線ではなく円環として扱われる。「動いて得た情報を持って、また『決めろ』へ戻る」——1回の対話で全部を解こうとしない設計だ。

質問の設計——LLMに「聞きすぎない」を守らせる仕掛け

このSkillでいちばん技術的に面白いのは、LLMが陥りがちな失敗を名指しで潰しにいっているところだ。対話型のプロンプトを書いたことがある人ほど、ここは読む価値がある。

まず、質問を出す前に通すゲートが3つ定義されている。

  1. 会話、指定された資料、利用できる環境から確認できないか
  2. 答えによって、見えていなかった前提か次の一歩が変わるか
  3. 本人にしか答えられず、いま考える価値のある問いか

そして「質問するのは、1では確認できず、2と3をともに満たす場合だけにする」と締める。すでに分かることを聞き返さない答えても何も変わらない問いを投げないという2つは、LLMとの対話がだるくなる原因そのものだ。

対話中は内部的に「地図」を持つよう指示される。着地点 / 確定したこと / いま扱える問い / まだ扱えないこと / 今回扱わないこと の5区分で、会話の状態を整理し続ける。そのうえで「地図を毎回すべて見せる必要はない」「まだ扱えないことを先回りして細分化せず、今回扱わないことを質問として戻さない」と、状態を verbalize しすぎないことまで指定している。エージェントに構造を持たせつつ、その構造を出力に垂れ流させない書き方だ。

さらに禁止事項が具体的である。「診断名や性格で説明しない。『怠け』『意志が弱い』『完璧主義だから』で片づけない」「早く前向きにさせようとしない」「強い言葉、羞恥心、説教で動かそうとしない」——最後には「見出しの命令形は行動の焦点であり、本人への非難ではない」という注記まで置かれている。「おい、とりあえず終わらせろ」という強い語感のタイトルを、エージェントが人格否定として再生産しないための予防線だ。

終了条件も明示されている。「ユーザーが疲れている、まとめを求めている、質問を止めてほしいと伝えた場合も、その時点の言葉でまとめる。不足欄を埋めるために対話を延ばさない」。テンプレートを持つLLMは空欄を埋めたがるので、その傾向に対する明示的な打ち消しになっている。

対話の着地点——4行のメモという固定フォーマット

対話は必ず決まった形に着地する。書籍の「4行のメモ」を中心にした、次のMarkdownだ。

## 今回の省察

- 何が起きたか:
- 自分は何を前提にしていたか:
- 実際にはどうだったか:
- 次は何を変えるか:

## 次の一歩

- 最初の一動作:
- 始めるきっかけ:
- 一周したとわかる印:
- 誰に何を確かめるか:

「埋まらない欄は省く」とされているので、全項目を埋めることは目的ではない。注目したいのは下段の「一周したとわかる印」という欄で、これは「どうなったら1周終わったと判断するか」を事前に決めさせるものだ。終わりの線が引けていないから止まる、という本書の見立てが、そのまま出力フォーマットに落ちている。

最後は「このまとめは、いまの感覚に合っていますか」と本人に確認して閉じる。ただしこれも「ユーザーが質問を止めるよう求めていた場合は、この確認も省く」と例外つきだ。あらゆる指示に例外条件が併記されているのがこのSKILL.mdの特徴で、231行という分量の多くはそこに使われている。

なお対話全体を貫く概念が「自分的完了と他者的完了」の区別である。自分が納得する地点(自分的完了)と、相手が「これで進められる」と判断する地点(他者的完了)は違う——このずれを見つけることが、5ステップの「決めろ」「出せ」で繰り返し問われる。エンジニアの文脈に置き換えれば、自分がマージしてよいと思う完成度とレビュワーが求める完成度のずれ、と読める。

【実測】oi-owaraseroを入れると、どのエージェントに何が置かれるのか

READMEは skills CLI 経由の導入を案内し、--agent claude-code codex で両方に入ると書いている。ここは実際に確かめる価値がある——「両対応」を名乗るツールが、実際にはどちらか片方にしかファイルを置いていないことは珍しくないからだ。

ユーザーの実環境を汚さないよう、独立した HOME を切って実行した。

# ユーザーの ~/.claude を触らないよう HOME を隔離して検証する
export HOME=/tmp/skill-test-home
mkdir -p "$HOME" && cd "$HOME"

# README に書かれているコマンドをそのまま実行
npx -y skills@latest add nwiizo/oi-owarasero \
  --skill oi-owarasero \
  --agent claude-code codex \
  --global

# 何がどこに置かれたかを確認する
find "$HOME" -maxdepth 4 \( -name "SKILL.md" -o -type l \) | grep -v node_modules
ls -la "$HOME/.claude/skills/"

CLI の出力は次のとおりで、導入自体は成功した。

◇  Installed 1 skill ───────────────╮
│                                   │
│  ✓ ~/.agents/skills/oi-owarasero  │
│    universal: Codex               │
│    symlinked: Claude Code         │
│                                   │
├───────────────────────────────────╯

出力を信じずファイルを直接見ると、実体はこうなっていた。

実際に置かれたもの 種別 解決するか
~/.agents/skills/oi-owarasero/SKILL.md 実ファイル
~/.claude/skills/oi-owarasero シンボリックリンク(→ ../../.agents/skills/oi-owarasero 解決した(リンク越しに SKILL.md が読めた)
~/.codex/ 作られない

つまり両対応は成立しているが、成立の仕方が2つのエージェントで違う。Claude Code には従来どおりシンボリックリンクが張られ、Codex は ~/.agents/skills/ という汎用パスを直接読むため専用ディレクトリを必要としない。CLIの出力にある universal / symlinked はこの差を指している。

当サイトの過去の検証結果を更新するskills.shとは|npx skills add がディスクに何を書くかを実測 で導入の実体を検証した際は「既定のシンボリックリンク方式で実際にリンクが張られるのは Claude Code だけ」という結果だった。今回 skills CLI 1.5.23 で測り直したところ、汎用パス方式との併用でCodex側も成立していた。バージョンが違えば結果が違うため、この種の「対応エージェント」の主張は測った版とセットで読む必要がある。

導入後、Claude Code 2.1.241 を隔離HOMEで起動して初期化イベントを覗くと、skills 配列の先頭に oi-owarasero が並び、slash_commands にも oi-owarasero が登録されていた。Claude Code から発見されていることはここまでで確認できる。

検証できなかったこと——「一覧に出る」と「実際に発火する」は別

正直に書いておく。このSkillが暗黙起動で実際に発火するかどうかは、本記事では検証できていない。

READMEは「Skillを明示しなくても、先延ばし、完璧主義、提出への怖さ、フィードバック後の停滞を振り返りたい依頼では、説明文をもとに選ばれることがあります」と書いている。SKILL.md の frontmatter を見るかぎり、これを妨げるものは無い——自動起動を禁止する disable-model-invocation のようなキーは設定されておらず、description には発火条件になる語(先延ばし・完璧主義・提出への怖さ・フィードバック後の停滞)が明示的に並んでいる。仕組みとしては暗黙起動が許可された状態だ。

しかし「許可されている」ことと「実際に選ばれる」ことは別である。この差は当サイトでも実測しており、grill-me は自動発火しない設計だった|mattpocock/skills 37本の起動条件を実測 では、一覧に載っていても発火しないSkillが実在することを確認している。「導入済み」は「使われる」を意味しない。

日本語の相談文を投げて Skill ツールの呼び出しが発生するかを stream-json で観測しようとしたが、隔離した HOME では Claude Code の認証情報が読めずNot logged in で停止)、実行に至らなかった。ユーザーの実環境へこのSkillを導入すれば測れるが、検証のために実環境を書き換えるのは避けた。

したがって本記事の結論は次の粒度で止める。インストールは実測で成立、Claude Code からの発見も実測で確認、暗黙起動の発火は未検証。確実に呼びたければ /oi-owarasero(Codex なら $oi-owarasero)と明示すればよく、そこは仕様として登録済みであることを確認できている。

他のAgent Skillと何が違うのか

Agent Skill として見たときの立ち位置を、当サイトがこれまで扱ってきたSkillと並べて整理する。

  oi-owarasero 一般的な作業支援Skill ドキュメント参照型Skill
目的 本人の省察を支える 作業を代行・高速化する 規約や作法を参照させる
成果物 4行のメモと次の一動作 コード・文章・調査結果 規約に沿った出力
同梱物 SKILL.md 1枚のみ スクリプト・MCP・テンプレート 参照ドキュメント群
AIの役割 問いを出す。答えは出さない 手を動かす 基準を当てる
成功の判定 本人が次の一歩を言葉にできた 作業が完了した 出力が基準を満たした
対象 人間の詰まり タスク 成果物

この表で言いたいのは優劣ではなく、評価軸が違うということだ。作業支援Skillは「速くなったか」で測れるが、このSkillは速くならない。測るとすれば「止まっていた理由を自分の言葉で言えるようになったか」であり、それは自動では判定できない。

技術的に見ると、SKILL.md 1枚・231行という構成は Agent Skill の最小形に近い。実行可能なコードもツール定義も持たないため、導入によって増えるのはコンテキスト上の指示文だけで、MCPサーバーのようにセッションごとの常駐トークンを恒常的に食うことはない(Skillは呼ばれたときに読み込まれる)。副作用の小ささという意味では、入れておいて損の少ない部類ではある。

一方で、SKILL.md がすべて日本語で書かれている点は評価が割れるところだ。日本語話者にとっては読みやすく、ニュアンス(「反省ではなく省察」「動ける粒度」)が正確に伝わる。ただし英語話者が中身をレビューするのは難しく、Skillを「実行前にレビューする」という運用(skills CLI 自身も導入時に Review skills before use; they run with full agent permissions. と警告する)とは相性が悪い。日本語圏に閉じた設計を選んだ結果であり、良し悪しではなく前提として押さえておきたい。

日本語圏での受け止められ方と、正直な期待値

日本発のリポジトリなので、英語圏OSSより日本語の需要が見込める。実測できた範囲では、はてなブックマークのエントリー数が 14(同日に検証した英語圏の別リポジトリは1)。★52という規模に対しては、日本語話者からの関心は相対的に高い。

この非対称は、題材の性質を考えると理解しやすい。★はGitHubを日常的に使う開発者の指標だが、はてなブックマークは日本語圏の読み物として拡散したかを示す。このSkillは「動くもの」より「読み物」として受け取られている——実行可能コードを持たず、価値の大半がSKILL.mdという日本語テキストにあることを踏まえると、その受け取られ方はむしろ内容と一致している。

ただし期待値は正直に見積もっておく。★52は当サイトが扱うOSSとしては小さく、検索需要という意味では oi-owarasero という固有名詞クエリ以外に受け皿が無い。書籍名『おい、とりあえず終わらせろ』には検索需要があると思われるが、そのクエリを打つ人が探しているのは書籍であってCLI用のSkillではないため、そこを狙うのは検索意図のミスマッチになる。本記事は書籍名ではなくSkill名を対象にしている。

更新状況とプロジェクトの規模感

「小さいから止まっている」のか「小さいまま完成している」のかは、コミット履歴で切り分けられる。実測すると、コミットは2本だけだった。

コミット 日時(JST) 内容
7d32afc 2026-08-25 12:48 [Skill] oi-owarasero を公開
a45f1ec 2026-08-31 14:06 [Skill] 対話フローと公開情報を更新

タグもリリースも0本、オープンIssue・PRともに0件。公開から6日後に一度更新が入り、そこから本記事執筆時点まで動きが無い。SKILL.md 1枚のプロジェクトなので、これは放置というより「書き切って安定した」状態と読むのが自然だ。ただし公開から日が浅く、長期的なメンテナンス姿勢を判断できる材料はまだ無い。ここは断定せず、事実だけを置いておく。

skills CLI 経由で導入すると、導入時にサードパーティのセキュリティ評価(Socket / Snyk 等)の結果が表示され、本Skillは Safe / 0 alerts / Low Risk と出た。実行可能コードを含まないリポジトリなので妥当な結果だが、これは「指示文の内容が安全」という保証ではない——静的スキャナは日本語のプロンプトが何をさせるかまでは読まない。skills CLI 自身が導入完了時に「使う前にレビューせよ」と警告するとおり、SKILL.md は自分で読むのが前提である。231行なので通読は現実的だ。

これは「作業が速くなるSkill」ではない。導入しても、コードが書かれる速度は1ミリ秒も変わらない。変わるのは「なぜ出せずに止まっているのか」を言語化する経路が1本増えることだけだ。生産性ツールとして期待すると確実に外す。

どういう人に効いて、どういう人には効かないか

最後に適合条件を整理する。

噛み合うケース:手は動くのに提出できない、という止まり方をよくする。レビューやフィードバックのあとに作業が止まる自覚がある。1人で開発していてレビュワーがおらず、振り返りの相手がいない。書籍を読んで内容には納得したが、実際の場面で使えていない。

噛み合わないケース:止まっている原因が技術的なブロッカー(仕様不明・環境が壊れている・依存の不具合)である場合。この種の詰まりは省察では解けないし、SKILL.md 自身が「終了条件が明確な実行依頼、単純な質問、軽微な修正では対話を始めず、そのまま依頼へ応える」と書いていて、対象外だと宣言している。また、AIに考える過程を代行してほしい人にも向かない——このSkillは最後まで「決めるのは本人」という立場を崩さない設計で、答えを出してはくれない。

総じて、これは「エンジニアの生産性ツール」の棚に置くと外すが、「AIエージェントに何をさせるかの設計例」として見ると学ぶところが多い1本だ。とくに、LLMがやりがちな失敗(空欄を埋めたがる・言い換えて聞き直す・すぐ前向きにさせる・性格で説明する)を1つずつ名指しで禁止していく書き方は、対話型のSkillやプロンプトを自作する人にとってそのまま参考になる。231行を通読して自分のSKILL.mdへ書き方だけ持ち帰る、という読み方も十分に成立する。

Agent Skill というフォーマットは、ツールを配るためだけのものではない。思考の手順そのものを配ることもできる、という実例として見ると面白い1本だ。エージェント側の全体像は AIエージェントフレームワーク比較2026|LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 が参考になる。

参照ソース