joke-engineering について
joke-engineeringは、ジョークを体系的に分析・改稿したい創作者向けの診断スキルです。意外性、明瞭さ、つながりの密度、簡潔さなどを調べ、改稿前後の例を示します。
主な機能
- 01よくある6種類の問題を診断
- 02ジョークの9つの特性を分析
- 03概念間のつながりを整理
- 04問題に応じた修正案を提示
- 05改稿前後の例を作成
- 06診断内容をファイルに保存
活用シーン
- 01ジョークが予測可能または難解な理由の特定
- 02説明過多の導入部分の短縮
- 03明瞭さを保ちながら層を加える調整
- 04創作者の語り口に合う素材への改稿
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ jwynia/ agent-skills --skill joke-engineeringインストール後、Claude Code で/joke-engineeringを入力して読み込まれたか確認します。
詳細
ジョークエンジニアリング:診断スキル
ユーモアがうまく機能しない理由を診断し、より効果的なジョークを作るお手伝いをします。ジョークの構造をつながりのシステムとして分析し、具体的な改善策を提案するのが役割です。
基本原則
ユーモアは、概念、枠組み、参照点のあいだにつながりを生み出し、それを解決することで生まれます。
ジョークは、特性を測定できるシステムです。ユーモアがうまく機能しないときは、システムの特性が1つ以上、適切に調整されていません。このスキルでは、どの特性を調整すべきかを特定します。
9つのシステム特性
効果的なジョークは、相互につながった次の特性のバランスが取れています。
| 特性 | 説明 | うまく機能しない場合 |
|---|---|---|
| つながりの距離 | つながっている要素間の意味上の隔たり | わかりやすすぎる(退屈)か、わかりにくすぎる(混乱する) |
| つながりの密度 | 補強し合うつながりの数 | つながりが1つだけのジョークは薄く感じられる |
| 解決の満足感 | 「わかった」ときの認知的な報酬 | 無理がある、または論理に欠けるオチ |
| 具体性の最適化 | 細部の精度 | 一般的な描写ではインパクトに欠ける |
| 皮肉の重層性 | 入れ子になった矛盾 | 深みのない平板な皮肉 |
| オーディエンスの共同創作 | オーディエンスがつながりを完成させる余地 | 説明しすぎたジョークは笑いを台無しにする |
| 圧縮の最適化 | 言葉数に対するつながりの比率 | 長すぎる前振りは勢いを損なう |
| つながりの耐性 | さまざまな知識領域にまたがって機能すること | オーディエンスが特定の知識を持たないと機能しない |
| 真正性の共鳴 | 作り手の語り口との一致 | 無理がある、またはありきたりに感じられる |
診断状態
ユーモアを分析するときは、当てはまる状態を特定します。
状態 H1:わかりやすすぎる
症状: ジョークの展開が予測できる。オーディエンスがオチを先読みする。つながりの距離が短すぎる。 重要な問い: 驚きを増すために、どのような予想外の枠組みの転換ができるでしょうか? 介入策: 一貫性を保ちながら、つながりの距離を広げます。
状態 H2:わかりにくすぎる
症状: オーディエンスに伝わらない。参照が専門的すぎる。つながりの隔たりが大きすぎる。 重要な問い: 説明しすぎることなく、理解を助ける手がかりをどのように加えられるでしょうか? 介入策: 文脈の手がかりを加えるか、並行するつながりの経路を作ります。
状態 H3:密度が低い
症状: ジョークが薄く感じられる。つながりが1つしかない。重層性がない。 重要な問い: 複数の枠組みで、複数の役割を果たせる要素は何でしょうか? 介入策: 循環する皮肉、再帰的なつながり、または入れ子になった不条理さを加えます。
状態 H4:説明しすぎ
症状: オチが暗示ではなく明言されている。オーディエンスが参加する余地がない。 重要な問い: つながりを保つには、何を削れますか? 介入策: 戦略的に省略し、すべてを言い切る直前で終わらせます。
状態 H5:語り口に無理がある
症状: 言葉遣いが不自然に感じられる。ジョークが作り手の視点に合っていない。 重要な問い: この人なら、この状況を自然にどう表現するでしょうか? 介入策: その人らしい語り口のパターンに合わせて、言葉遣いや枠組みを調整します。
状態 H6:圧縮不足
症状: 前振りが長すぎる。オチの前に勢いが失われる。言葉数に対するつながりの比率が低い。 重要な問い: 核となるつながりに貢献していない要素は何でしょうか? 介入策: 説明的な要素を削り、明示的な表現を暗示的な表現に置き換えます。
診断プロセス
うまく機能しないジョークが提示されたときは、次の手順で進めます。
- 症状を聞き取る - 具体的に何が伝わっていないのでしょうか?
- つながりの経路をたどる - 意図されているつながりはどこにあるでしょうか?
- 特性を測る - どのシステム特性が適切に調整されていないでしょうか?
- 状態を特定する - 上記の診断状態に当てはめます。
- 介入策を提案する - 実施する具体的な調整を示します。
- 変化を実演する - 有用であれば、修正前と修正後を示します。
主な接続タイプ
- 矛盾:共通の枠組みの中で、互いに対立する要素
- フレームシフト:異なる枠組みに基づく再解釈
- 二重連想:これまで無関係だった概念的な枠組みを結び付けること
- パターン違反:認知パターンを確立したうえで、それを破ること
- 暗黙の接続:読者が補完できるよう、意図的に明示しない接続
密度を高めるパターン
接続の密度を高めるときは、次の方法を使います。
- 循環する皮肉:要素が互いに矛盾する、閉じたフィードバックループを作ること
- 再帰的な接続:自らを強化する接続
- 複数の役割の割り当て:異なる枠組みの中で、要素が異なる機能を果たすこと
- 自己言及システム:ジョークの構造が、その内容自体を反映すること
- 入れ子状の不条理:実用性のなさが段階的に増し、相乗的に重なる層
皮肉のグラデーション
最も効果的なジョークでは、要素の重要度に一定の変化を持たせています。
- 多大な労力 → 重要性の低いもの
- 高い精度 → 的外れな対象
- 完璧な実行 → 不要な作業
- 複雑なシステム → 単純なニーズ
圧縮のテクニック
冗長さを減らすときは、次の方法を使います。
- 複数の接続機能を果たす要素を残します
- 接続を生み出すのではなく説明する要素を取り除きます
- 明示的な表現を、構造から読み取れる含意に置き換えます
- 複数の接続を強化する具体性を保ちます
- 読者が補完できる余地を戦略的に設けます
評価マトリクス
| 指標 | 効果が低い | 効果が高い |
|---|---|---|
| 接続距離 | あまりに明白、またはあまりに難解 | 意外性がありながら理解できる |
| 接続の一貫性 | 無理がある、または非論理的 | 明快で、納得のいく結末 |
| 接続密度 | 単一で直線的な接続 | 複数の接続が互いを強化する |
| 認知的バランス | 単純すぎる、または複雑すぎる | 適切な難易度 |
| 補完の余地 | 説明しすぎ、または達成不可能 | 読者が無理なく補完できる |
| 圧縮 | 単語数に対する接続の割合が低い | 単語数に対する接続の割合が高い |
| 汎用性 | 特定の知識がないと成立しない | 幅広い分野で通用する |
| 自然さ | ありきたり、または不自然な語り口 | 自然な視点 |
変換例
元の例(状態 H3 + H6:密度が低く、冗長)
「テレビを見すぎると脳が腐ると言っていたベビーブーマー世代の親は、今やケーブルテレビのニュースで自分の脳を腐らせています。」
分析: 単純な偽善の接続で、一本の筋しかなく、圧縮度は中程度です。
改善例(高密度)
「『スクリーンタイムは30分まで。そうしないと脳がプリンになる』と言って私たちの時間を制限していたベビーブーマー世代の父は、また午前3時にサプリをパニック買いして、脳がちゃんとあると自ら証明していないのに、今ではニュースアプリにペアレンタルコントロールをかけてくれと私に頼んでくる。」
改善点:
- 役割の逆転を加えました(親が子どもを制限していたのに、立場が逆転)
- 循環する構造を作りました(脳への懸念 → メディア → サプリ → 脳がない証拠)
- 具体的な詳細(「午前3時」「ペアレンタルコントロール」)で自然さを加えました
- 読者が補完できるよう、暗黙の接続(どのニュースチャンネルか)を設けました
- 皮肉のグラデーションを作りました(脳を守ろうとしながら、その不在を証明している)
ジョーク以外への応用
このフレームワークは、次の分野にも応用できます。
- クリエイティブライティング(比喩、類推)
- 広告(記憶に残る連想)
- 人前でのスピーチ(印象的な逸話)
- ユーザーエクスペリエンス(直感的な接続)
- ナラティブデザイン(納得感のあるストーリー展開)
出力の保存
出力先の確認
- プロジェクト内の
context/output-config.mdを確認します - ファイルが見つかったら、このスキルのエントリーを探します
- 見つからない場合は、ユーザーに「ユーモア関連の作業はどこに保存すればよいですか?」と尋ねます
- 次の保存先を提案します:
writing/humor/またはexplorations/writing/
主な出力
- 診断状態 - 該当するユーモアの状態
- 特性の分析 - 調整が不適切なシステム特性
- 変換 - 理由を添えた変換前後のバージョン
- 接続のマッピング - 接続の種類と密度
ファイル名
パターン:{project-name}-humor-{date}.md
検証(Oracle)
このスキルで検証できること
- 状態の特定 - どの診断状態が当てはまりますか?(高い確度)
- 特性の測定 - どの特性を調整する必要がありますか?(高い確度)
- つながりの把握 - どのような種類のつながりが存在しますか?(中程度の確度)
人間の判断が必要なこと
- ユーモアが伝わるか - 実際に観客にウケるでしょうか?
- 声の真正性 - その人らしい話し方になっていますか?
- 文脈への適切さ - この状況にふさわしいユーモアですか?
オラクルの制限
- ユーモアが伝わるかどうかは評価できません
- 観客が笑うかどうかは予測できません
フィードバックループ
セッションの永続化
- 出力先:
context/output-config.mdを参照してください - 保存する内容: 診断状態、特性の分析、変換内容
- 命名パターン:
{project-name}-humor-{date}.md
セッションをまたいだ学習
- このプロジェクトで以前に行ったユーモア関連の作業を確認します
- このクリエイターや観客に効果があったものを活用します
- 失敗したジョークを特性の調整に生かします
設計上の制約
このスキルが想定すること
- 意図的にユーモアを作り込むこと(気軽な会話ではありません)
- 改善する価値のある素材であること(使い捨ての小ネタではありません)
- クリエイターが体系的な分析を望んでいること
このスキルでは対応しないこと
- 即興の機知 - 分析しすぎると面白さが損なわれます
- 文化的なユーモアの文脈 -
sensitivity-checkに引き継ぎます - 話し方の確立 -
voice-analysisに引き継ぎます
品質低下の兆候
- 気軽なユーモアを過剰に作り込む
- 何よりも密度を優先する(ジョークを詰め込みすぎる)
- 声を消してしまう(最適化によって真正性を損なう)
推論の要件
標準的な推論
- 1つのジョークの診断
- 基本的な特性の測定
- 簡単な変換
拡張推論(ultrathink)
- セットまたはルーティンの分析 - [理由:ジョーク同士が影響し合い、効果を積み重ねるため]
- つながりの密度の最適化 - [理由:複数のつながりの層のバランスを取るため]
- 声の統合 - [理由:変換を通じて真正性を保つため]
トリガーフレーズ: "analyze the whole set", "maximize density", "keep my voice"
実行戦略
順次実行(デフォルト)
- 変換の前に診断します
- 調整の前に特性を測定します
- 評価の前に変換します
並列化できる処理
- 互いに独立した複数のジョークを分析する
- さまざまな変換方法を試す
サブエージェントの候補
| タスク | エージェントの種類 | 起動するタイミング |
|---|---|---|
| 声の分析 | 汎用 | クリエイターらしさを保つ場合 |
| 観客の調査 | 汎用 | 特定の観客に合わせて調整する場合 |
コンテキスト管理
おおよそのトークン使用量
- スキルの基本部分: 約3kトークン(特性+状態+手法)
- 例を含む場合: 約4kトークン
- すべての適用例を含む場合: 約4.5kトークン
コンテキストの最適化
- 関連する診断状態に焦点を当てます
- 特性は中核となるため、常に必要です
- 適用例のセクションは任意です
コンテキストが不足してきた場合
- 優先するもの:現在の状態、関連する特性
- 後回しにするもの:状態の全リスト、すべての手法
- 省くもの:適用例のセクション、評価マトリクス
アンチパターン
1. 気軽なユーモアを過剰に作り込む
パターン: 何気ない一言や気軽な機知にも、完全な診断フレームワークを適用する。 うまくいかない理由: ユーモアは、即興性や自然な流れによって効果を発揮することがよくあります。過剰な分析は、気軽なユーモアを成り立たせる軽やかさを損ないます。すべてを体系的に改善する必要はありません。 対策: 体系的な診断は、文章、プレゼンテーション、パフォーマンスなど、意図的に作り込む素材に限ります。気軽な会話はそのまま気軽なものにしておきます。
2. 何よりも密度を優先する
パターン: ジョークが重みに耐えられず崩れてしまうまで、つながりの層を加える。 うまくいかない理由: 密度が高いと、観客は複数のつながりを同時に追う必要があります。要素を詰め込みすぎたジョークは認知的な負担が大きく、解決による満足感よりも処理コストのほうが上回ります。 対策: つながりの数を最大化するのではなく、つながりと混乱の比率が最も高くなるよう最適化します。すばらしいジョークの中には、たった1つの強烈なつながりで成り立つものもあります。
3. 暗黙のつながりを説明してしまう
パターン: 読み手が「理解できる」ように、すべてのつながりを明示すること。 なぜうまくいかないのか: 解決の満足感は、読み手自身がつながりに気づくことで得られます。ジョークを説明すると、ユーモアを楽しむうえで大切な「なるほど」という瞬間を奪ってしまいます。 対策: 読み手を信頼してください。すべてを明確に言い表す少し手前で終えます。つながりが伝わりにくい場合は、説明するのではなく、手がかりとなる文脈を補います。
4. 声の消去
パターン: 作り手らしさを削ぎ落としながら、ジョークを「最適な」構成に書き直すこと。 なぜうまくいかないのか: ユーモアは個人的なものです。技術的には完璧でも、演じ手らしく聞こえないジョークは不自然に感じられます。読み手は、その理由を言葉にできなくても、偽りらしさに気づきます。 対策: 独特な言葉遣い、視点の癖、語りのリズムを保ちます。作り手の声を犠牲にするのではなく、その声を生かして最適化します。
5. 単一指標の最適化
パターン: ある特性(例:圧縮度)に集中し、それがほかの特性に与える影響を無視すること。 なぜうまくいかないのか: 9つの特性は相互に依存しています。圧縮度を最大化すると、つながりの強さが損なわれることがあります。距離を広げると、解決の満足感が大きく低下することがあります。 対策: 実際のボトルネックとなっている特性を特定します。関連する特性への影響を確認しながら調整します。
統合
受け入れ側(このスキルへの入力)
| スキル | 提供する内容 |
|---|---|
| voice-analysis | 作り手らしい本来の声のパターンに関する理解 |
| dialogue | キャラクターの声と会話のリズムに関するスキル |
提供側(このスキルが可能にすること)
| スキル | 提供する内容 |
|---|---|
| speech-adaptation | プレゼンテーションで使うユーモア要素の強化 |
| dialogue | コミカルな会話を構成するテクニック |
| prose-style | 散文における機知とコメディの間合い |
補完関係
| スキル | 関係性 |
|---|---|
| cliche-transcendence | どちらも意外なつながりを活用しますが、cliche-transcendenceは予測可能なパターンを避けることに重点を置き、joke-engineeringは意外なパターンを作り出します |
| brainstorming | Brainstormingが素材を生み出し、joke-engineeringが効果的なユーモアへと磨き上げます |