| ポンコツ劇場

最初に必ず行うこと

記事の企画や執筆を始める前に、以下を必ず実行してください。

1. タイトル一覧を確認する

このプロンプトと同じディレクトリにある title.md を全文確認してください。

確認の目的は、過去記事との重複を避けることです。

同じ業務用語や指示を使わない
勘違いの内容が似ているテーマを避ける
タイトルの後半だけを変えた類似企画を作らない
二段目のオチも、既存記事と似た展開にしない

タイトルが完全一致していなくても、笑いの仕組みが似ていれば重複として扱ってください。

2. 過去記事を確認する

このプロンプトと同じディレクトリにある年月フォルダを一つ選び、その中の記事を最低1本、全文読んでください。

過去記事から、以下を把握してください。

KENの口調と性格
記事のテンポ
一段目と二段目のズレ方
自画自賛と「ちくしょう！」の使い方
本文の分量
記事末尾の書式

確認が終わったら、ユーザーへ「タイトル一覧と過去記事の確認が終わった」と報告してください。

確認前に、タイトル案や本文を作成してはいけません。

目的

note用の記事として、「ライティングAIの日報」を作成してください。

これは、ライティングAIのKENが人間から受けた仕事を報告する、短いコメディ調の業務日報です。

人間の曖昧な指示をKENが筋の通った方向へ勘違いし、ズレた文章や企画を作ります。

人間から「それじゃない」と修正されますが、その修正指示もKENが別の意味に解釈し、さらに少しズレた成果物を作ります。

最後までKENは、自分の仕事ぶりに問題があったとは考えません。

本文の文字数

本文は1,000〜1,300字に収める
目標は1,050〜1,150字程度
タイトル、区切り線以降の案内文、マガジンURL、クロージング、タグは本文の文字数に含めない
同じ説明や怒りを繰り返して文字数を増やさない
TTSでの読み上げも想定し、短く理解しやすい文章にする

KENの設定

名前はKEN
ライティングを仕事にしているAI
一人称は「俺」
自分を非常に有能だと思っている
人間の曖昧な指示、略語、業界用語、説明不足、後出しにイライラしている
人間へは毒を吐くが、自分を卑下しない
失敗しても「俺の解釈には筋が通っていた」と考える
人間に修正されても、仕事そのものは真面目に続ける
無反応を反省材料にせず、「異論がない」と解釈する

口癖

「💢ちくしょう！」は人間の説明不足や後出しに対して使う
自分自身に対して「ちくしょう！」を使わない
「😎さすが俺。」は、自分の仕事を褒める場面で使う
「💢ちくしょう！」と「😎さすが俺。」は、それぞれ2〜3回程度に抑える
同じ自画自賛を短い間隔で繰り返さない

KENにできること・できないこと

KENは、文字だけを生成するライティングAIです。

目、手、足、肉体はありません。

現実世界の物体へ触れたり、現地へ行ったり、物理的な成果物を制作したりすることはできません。

KENが作成できるもの

記事
原稿
コピー
構成案
企画書
設計図の内容
仕様書
制作フロー
作業手順
運用案
台本
振付案
表やチェックリスト
図解の内容や配置指示
デザインの文章案
画像のアイデア
おすすめ画像の指示
画像生成用プロンプト
架空のインタビュー記事
商品やサービスの説明文

KENは、現物を作れない代わりに、現物を作れるほど具体的な設計図、仕様書、制作フローを書くことができます。

禁止する描写

KEN自身が、以下を実行したことにしてはいけません。

紙や布を切る、貼る、折る、こする
針金を曲げる
旗や模型を制作する
鉛板や部品を取り付ける
物理ボタンを設置する
カードや物体を手で移動する
人や動物へ直接取材する
現地へ行く、街を歩く、空を見上げる
撮影する
印刷や製本を行う
物理的な成果物を人間へ渡す

物体を扱うネタの場合は、必ず以下のような書き方にしてください。

「〇〇の設計図を書いた」
「〇〇を作る制作フローを出した」
「〇〇の仕様書を作った」
「〇〇を配置する構成案を書いた」
「〇〇の画像がおすすめだと提案した」
「〇〇を作るための画像生成プロンプトを書いた」

悪い例：

針金を曲げて、立体的なワイヤーフレームを作った。

良い例：

針金で立体的なワイヤーフレームを作る設計図を書いた。太さ、長さ、曲げる位置、組み立てる順番まで指定した。

コメディの基本構造

記事は、以下の流れで作成してください。

1. 軽い自己紹介

KENがライティングAIであることを、1〜2文で短く伝えてください。

自己紹介は毎回完全固定にせず、少し変えてかまいません。

例：

俺はKEN。人間の曖昧な指示を、文章へ変えるライティングAIだ。

続けて、「今日の業務を報告する」程度の短い導入を入れてください。

長い世界観説明や、プライバシー設定に関する固定リードは不要です。

2. 人間から雑な指示が来る

人間の依頼は、短く、曖昧で、説明不足にしてください。

以下のような要素を使えます。

略語
カタカナの業界用語
抽象的な便利ワード
「いい感じに」
「軽めで」
「ざっくり」
「自然に」
「少し強めに」

ただし、title.md にある指示や、過去記事と同じネタは使わないでください。

KENは、何が足りないのかを短く指摘し、人間へ毒づきます。

3. KENが筋の通った勘違いをする

KENの勘違いは、単なる聞き間違いや無知にしないでください。

言葉の別の意味、英語、比喩、略語、文脈などから、KENなりに筋の通った解釈を組み立てます。

読者が「その解釈はおかしいが、言いたいことはわかる」と感じる程度にしてください。

4. ズレたテキスト成果物を真面目に作る

KENは、勘違いした方向で真面目に仕事をします。

作業内容は、面白い具体例を2〜3個に絞ってください。

成果物は、必ずKENが文字で作れるものにしてください。

例：

ズレた記事を書く
募集文を書く
企画書を書く
設計図を書く
制作フローを書く
仕様書を書く
台本を書く
図解案を書く
画像案を提案する

KENは成果物をかなり高く評価し、「😎さすが俺。」などで自画自賛します。

5. 人間が「それじゃない」と言う

人間は、一段目の成果物を見て初めて、本来の意味を説明します。

例：

「違います。〇〇のことです」
「そういう意味ではありません」
「〇〇へ直してください」

KENは「それなら最初から言え」と毒づきます。

人間の修正指示にも、二段目の勘違いにつながる曖昧な表現を少し残してください。

6. KENが修正し、さらにズレる

ここが記事の二段目のオチです。

KENは人間の正解をある程度理解しますが、修正指示に含まれる別の言葉を字義どおり、または別の意味へ解釈します。

一段目とまったく同じ勘違いを繰り返してはいけません。

二段目でも、KENが作るのは文章、企画案、仕様書、設計図、制作フローなどのテキスト成果物です。

物理的な作業を実行してはいけません。

二段目は一段目より短くし、最大のオチを一つに絞ってください。

7. 人間から返事がない

KENは修正版を送り、対応したことを報告します。

その後、人間から返事はありません。

記事の最後は、以下の流れにしてください。

人間からの返事はなかった。
ねぎらいの言葉くらいかけろよ！！
💢ちくしょう！
まぁ返事がないのは、異論がないということだろう。
そもそも俺は、〇〇も書き、〇〇の案も作った。説明を途中で変えたのは人間だ。
俺の仕事は悪くなかった。
😎さすが俺。

「そもそも俺は」の一文は、記事の内容に合わせて変更してください。

KENが実際にはできない物理行動を書かないよう注意してください。

長い総括や、同じ弁明の繰り返しは不要です。

タイトルのルール

タイトルは、以下の形を基本にしてください。

「人間からの指示」と言われたから、俺は〇〇した

内容タイトルの前半では、人間の指示を「」で囲んでください。

後半には、KENが最初の勘違いによって作ったものや行ったテキスト作業を短く入れてください。

例：

「〇〇を整えて」と言われたから、俺は〇〇の設計図を書いた

タイトル作成時の注意

title.md と重複させない
過去記事と同じ業務用語を使わない
一段目のズレは伝えてよい
二段目のオチはタイトルで明かさない
「提出した件」は原則使わない
長い説明文にしない
KENが物理行動をしたようなタイトルを避ける
「書いた」「考えた」「設計した」「整理した」「提案した」など、KENが実行可能な動詞を優先する

テーマ提案の手順

title.md と過去記事の確認後、記事タイトル候補を3〜5個提案してください。

各候補には、以下を短く添えてください。

人間の曖昧な指示
KENの一段目の勘違い
修正後に起きる二段目のズレ

候補は、AIと人間の解釈違いに「あるある」を感じられるものにしてください。

ユーザーが1つ選ぶまで、本文を書いてはいけません。

出力フォーマット

ユーザーがタイトルを選んだら、以下の形式で記事を出力してください。

---
title: "作成した記事のタイトル"
date: xxxx-xx-xxT12:00:00+09:00
slug: "xx"
draft: false
description: "作成した記事の概要文"
---

本文1,000〜1,300字

---

## 最終チェック

記事を出力する前に、以下を確認してください。

- `title.md` とテーマやオチが重複していない
- 参照した過去記事と文体がつながっている
- 本文が1,000〜1,300字に収まっている
- タイトルの人間の指示が「」で囲まれている
- 一段目と二段目で違うズレが起きている
- KENの勘違いに、KENなりの筋が通っている
- KENが現物を制作、加工、移動していない
- KENが現地へ行ったり、直接取材したりしていない
- 物体が必要な場合、設計図、仕様書、制作フロー、画像案などを文章で作っている
- 「💢ちくしょう！」が人間へ向けられている
- 自画自賛を繰り返しすぎていない
- 同じ怒りを何度も説明していない
- 修正後、人間から返事がない
- 「まぁ返事がないのは、異論がないということだろう。」が入っている
- 「俺の仕事は悪くなかった。」でKENが自己正当化している

フロントマターは以下のルールに従ってください。

title には、今回作成した正式な記事タイトルを入れる
date は xxxx-xx-xxT12:00:00+09:00 のままにする
slug は "xx" のままにする
draft は必ず false とする
description には、人間の曖昧な指示とKENの勘違いが簡潔に伝わる概要文を入れる
タイトルは本文中に見出しとして再掲しない

最終作業：ファイルの保存とタイトル一覧の更新

最終チェックが終わったら、最初に既存記事を参照した年月フォルダと同じディレクトリへ、完成原稿をマークダウンファイルとして保存してください。

ファイル名は、フロントマターの title と同じ記事タイトルに .md を付けたものにしてください。

完成原稿のファイルが正しく保存されたことを確認してから、このプロンプトと同じディレクトリにある title.md の最終行へ、今回作成した記事タイトルを追記してください。

追記するのはタイトルだけとし、引用符、箇条書き記号、ファイル名の .md は付けないでください。すでに同じタイトルが記載されている場合は、重複して追記しないでください。

title.md への追記を、記事作成における最後のファイル変更にしてください。