0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

140文字の無茶ぶりで、ホームページそのものを改修する実験を始めた

0
Posted at

個人開発のいいところは、何を作るか自分で決められることです。

そこで、何を作るかを訪問者の要望とAIの解釈に任せるサイトを作りました。

せっかく手に入れた裁量を、玄関先で配っています。

After 6 Chaos という個人開発のサイトです。140文字以内の要望を受け付け、AIがまとめて読み、サイト自体を改修します。

家に例えるなら、玄関に目安箱があり、通りすがりの要望で増改築の話が進む仕組みです。家主にも相談してほしいところですが、その箱を置いたのが家主です。

今回は、要望の受付から、翌日以降の改修、対応結果の公開までをどうつないだかを書きます。

発注書に「海」とだけ書いてあったら

例えば「海」という一語でも投稿できます。ここからの「海」は説明用の架空の要望ですが、工事業者に渡したら打ち合わせが一回増えそうです。

写真を置くのか。背景を青くするのか。釣りゲームを作るのか。140文字の上限を設けたところ、一文字で話がややこしくなっています。

Chaosでは、その解釈も含めてAIに任せます。複数の要望を組み合わせることも、既存の画面を変えることもあります。1投稿から必ず1機能を作る、という対応にはしていません。

青い背景になるのか、波が動くのか、そもそも採用されるのかは、その時の改修次第です。

自由にする一方、受付には小さな制限を付けました。

制限 現在の扱い
1件の長さ 1〜140文字。見た目の文字数を Intl.Segmenter で数える
1日の受付 サイト全体で10件。日本時間の0時に切り替える
連続投稿 同じ接続元からは60秒空ける

文字列の .length だけで数えると、絵文字などが見た目どおりの文字数になりません。入力の自由さを売りにするなら、「140文字」のほうも人間の見た目に寄せたいところです。

受付係は、その場で壁を抜かない

構成は、Reactの画面、Cloudflare WorkersのAPI、D1の投稿保存、そしてChatGPT側の定期実行タスクです。

担当 やること
サイトのAPI 文字数や受付上限を確認し、投稿をD1に保存する
定期実行タスク 対象の投稿を読み、ソースを改修して確認・公開する
公開サイト 改修後のページと、投稿への対応結果を表示する

投稿APIの仕事は、受付条件を確かめて保存するところまでです。受付係は、いったん伝票を預かります。窓口で「海」と言った瞬間に壁を抜き始める構成にはしていません。

AIによる改修は、ChatGPT側の定期実行タスクが担当します。対象になるのは、受付日の翌日3時以降の改修です。処理が終わって公開されてから反映されます。

「送れた」と「できた」の間には工事があります。投稿直後には、まだ受付が済んだ段階です。

また、投稿は改修の材料です。投稿文に「フォームを消して」と書かれても、それだけで改修範囲が広がる扱いにはしません。

増築してよい。でも玄関は残す

サイトを自由に改修してよいとしても、次の要望を送る入口まで消えると、実験がそこで止まります。「玄関を戻してほしい」という要望を、どこから送ればいいのか分かりません。

そこで、ページの改修領域と、投稿フォーム・改修履歴・受付処理などの共通部分を分けています。共通部分は改修対象から外し、固定ファイルの変更も検査します。

CSSも改修するページの領域に収める方針です。背景を海にしたかっただけなのに、投稿フォームまで沖へ流されると困ります。

この分け方は、AIの変更権限を技術的に完全隔離するものではありません。改修範囲の指定に加えて、固定部分の検査と公開前の確認を組み合わせています。

自由に変わるページと、次も参加できる入口。この2つを一緒に残すための境界です。家主の決めた間取りは変わっても、話を聞く場所は残します。

「できました」だけで竣工扱いにしない

もうひとつ分けたのが、投稿の保存と、対応済みの判定です。

投稿本文はD1に保存します。対応結果は、サイトと一緒に公開する data/changes.json に記録します。各改修には対象の投稿IDと、採用・不採用を含むコメントを持たせています。

未対応の投稿を求める考え方は、次のとおりです。説明用に簡略化しています。

const used = new Set(
  changes.flatMap(change => change.submissionIds)
);
const pending = posts.filter(post => !used.has(post.id));

公開されている改修履歴に含まれる投稿を、対応済みとして扱います。AIが「できました」と言っただけで、投稿を消化済みにはしません。

不採用になった投稿も、理由を履歴に残せば対応済みです。そうしないと、毎朝同じ伝票が工事担当に戻ってきます。目安箱に入れた一言が、採用されるまで毎朝ドアをたたきに来る仕組みになってしまいます。

履歴が壊れていた場合も、受付済みの投稿を勝手に消化しないことを確認しました。完成したページと、何に対応したかの記録をそろえて公開する仕組みです。

施工実績は、これからです

正式公開に合わせて、試験用の投稿と改修履歴はリセットしました。この記事を確認した2026年10月31日時点では、公開後の改修履歴は0回です。

つまり、受付も工事の段取りも、記録を残す仕組みもありますが、公開後の施工実績はまだありません。現場監督の説明だけが、ずいぶん長くなりました。

実装・検証・執筆には生成AIを使っています。文字数・受付制限・改修対象日の判定・履歴と対応済み判定については、現行ソースのテストを実行して確認しました。

家主の仕事が一つ増える

何を作るかを訪問者の要望とAIに任せるために、受付・改修・対応済みの判定を分けました。変更範囲を決め、次の投稿の入口を守り、公開された履歴で何に対応したかを確かめます。

どんな要望が届き、どう解釈されるか。増改築が始まったら、「海」が青い壁で済むかどうかも含めて、家主にもまだ分かりません。

自分で決められるのが個人開発のいいところだと書きました。決める部分を人に開いたので、今度は自分も完成形を見る側に回れます。何か届けば、ですが。

自分の家なのに、次の間取りは内見してからのお楽しみです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?