編集者GPT、校正GPT、画像生成GPT、WordPress整形GPT、note用GPT。目的ごとに分ければ、毎回同じ説明をしなくて済む。最初は、自分専用のAI担当者が少しずつ育っていくようにも見える。

ただ、実際に使ってみると、そこは少し違った。

GPTsは、前回までを覚えて育つ相棒ではない。

OpenAI Help Centerでは、custom GPTsは現在メモリ非対応であり、過去セッションの文脈を保持しないと説明されている。ユーザー側で通常のChatGPTメモリをオンにしていても、custom GPTsの各interactionはステートレスで始まる。

つまり、GPTsに「前回の続きで」「前回決めた方針を踏まえて」と期待しすぎると苦しくなる。

では、GPTsに価値がないのかというと、そうではない。

GPTsの現時点での実感値としての価値は、記憶ではなく型の固定にある。毎回同じ役割、同じ初期条件、同じ出力フォーマット、同じ会話スターター、同じ目的の入口で始められることに意味がある。

この記事では、GPTsを「育つ相棒」ではなく「型化された入口」として考え直す。

GPTsは便利だが、育つ相棒ではなかった

GPTsは、特定の目的向けに設定したChatGPTである。

OpenAI Help Centerでは、GPTsはInstructions、Knowledge、Capabilities、Actionsなどを組み合わせて、目的に合ったChatGPTを作れるものとして説明されている。

Instructionsでは、役割、口調、目的、境界を設定できる。Knowledgeでは、参照資料をアップロードできる。Capabilitiesでは、画像生成やWeb検索などの機能を選べる。Actionsでは、外部APIと接続できる。

ここだけ見ると、GPTsはかなり強い。

ただし、重要な制約がある。custom GPTsはメモリ非対応であり、過去セッションの文脈を保持しない。各会話は基本的に新しく始まる。

そのため、GPTsは「前回までの内容を踏まえた長期プロジェクト管理」には向きにくい。

たとえば、記事シリーズで次のような使い方をしようとすると、だんだん重くなる。

• 前回の記事で決めた方針を覚えていてほしい
• 記事シリーズ全体の進捗を管理してほしい
• 前回やめた判断を次回も自動で引き継いでほしい
• 途中で変えた編集方針を覚え続けてほしい

こういう用途は、GPTsだけで抱えるより、ProjectsやCodex側のファイル管理に寄せた方がよい。

ここを誤解すると、GPTsに期待しすぎる。

GPTsを否定するものではない。ただし、記憶で育つ道具として見るより、毎回同じ型で始める道具として見た方が安定する。

GPTsで困ったこと

GPTsで困りやすいのは、前回までの方針を自動で引き継げないことだ。

たとえば、ブログ記事制作で「このシリーズでは第1弾で機能比較、第2弾でPersonalityとメモリ、第3弾でGPTs運用を扱う」と決めたとする。

通常のChatGPTやProjectsの文脈がある場所なら、その流れを会話の中で扱いやすい。しかしcustom GPTsでは、過去セッションの文脈を保持しない。次に開いたときは、基本的に新しい会話として始まる。

もちろん、Knowledgeに資料やルールを入れれば参照はできる。

しかし、Knowledgeは手動で追加・更新する必要がある。記事シリーズの進捗や最新判断を、毎回Knowledgeへ反映し続けるのは個人運営では重い。

固定資料には向いている。

• ブログの基本方針
• 文体ルール
• 固定のチェックリスト
• あまり変わらない仕様メモ
• 画像生成時の基本条件

一方で、更新頻度が高い情報には向きにくい。

• 記事シリーズの進捗
• 前回の判断変更
• 今回だけの編集方針
• 公開前の残タスク
• 実作業中に変わるメモ

こうした情報は、Projectsに置くか、Codexで管理しているファイルに残す方が扱いやすい。

Knowledgeは「固定資料」や「あまり変わらない前提」に向く。日々変わる運用状況や進捗管理を入れ続ける場所としては、少し重い。

ファイルを直す作業はCodexに寄せた方がよさそう

GPTsを編集者や校正役として使うことはできる。

ただ、記事ファイルを扱う作業では、Codexの方が運用に乗りやすい場面がある。

たとえば、誤字脱字、表記ゆれ、Markdown整形、WordPress用整形、一括修正のような作業である。

Codexはファイル単位で扱える。複数ファイルを読み、既存ナレッジとの整合を確認し、差分を見ながら修正できる。Markdownファイルとして記事を管理しているなら、修正前後の差分を確認しやすい。

これは、GPTsやChatGPTが不要という意味ではない。

方向性レビューや読者視点の違和感チェックは、GPTsやChatGPTにも価値がある。記事の主張が伝わるか、読者がどこで迷うか、タイトルと本文のズレがないかを見るなら、会話型のレビューは使いやすい。

ただし、ファイルを直す作業、整形する作業、複数箇所を一括で揃える作業は、Codexに寄せた方が安定する可能性がある。

ここも役割分担で考える。

GPTsはレビューの入口として使える。Codexはファイルを直す作業に向く。どちらか一方に寄せるより、作業の種類で分けた方がよい。

ではGPTsの価値はどこにあるのか

GPTsの価値は、記憶ではなく型化された入口にある。

毎回「あなたは○○です」と言わなくてよい。目的別の入口を作れる。出力フォーマットを固定しやすい。会話スターターを用意できる。初心者や未来の自分が、何を頼めばよいか迷いにくい。

たとえば、次のような作業には向いている。

• 画像生成の条件を毎回そろえる
• 特定用途のプロンプトを作る
• 決まった形式でレビューする
• 初心者向けに手順案内を始める
• 決まった会話スターターから作業を始める

GPTsは「成長して覚えてくれる担当者」ではなく、「毎回同じ初期条件で始められる入口」と見る。

この見方にすると、GPTsを増やす基準も変わる。

長期記憶が必要なものはGPTsに向かない。初期条件を固定したいもの、出力フォーマットを安定させたいもの、同じ目的で繰り返し始めたいものはGPTsに向く。

GPTsは覚えてくれるから便利、ではなく、毎回同じ場所から始められるから便利。ここを間違えると、期待値が少しずつズレる。

LINEスタンプ画像生成ではGPTsが効いた

IMEER LABでGPTsが効いた例として、LINEスタンプ画像生成がある。

画像生成では、毎回条件を書くのが地味に重い。

• LINEスタンプ向けの画像であること
• 370×320を意識すること
• 余白を確保すること
• 背景を扱いやすくすること
• 文字を入れるか、入れないか
• キャラクター設定を崩さないこと
• ロコ太などのキャラクター前提を踏まえること

通常のChatGPTで毎回説明してもよい。だが、毎回同じ初期条件を書くのは面倒である。

GPTsにしておくと、「LINEスタンプ用画像生成の入口」として始められる。最初から、LINEスタンプ向けの画像生成、キャラクター設定、背景、余白、サイズ、文字の扱いを固定しやすい。

ここで効いているのは、長期記憶ではない。

前回の作業を覚えてくれることではなく、毎回同じ型で始められることが効いている。画像生成プロンプトの型が安定し、相談の立ち上がりが速くなる。

もちろん、これも万能ではない。

キャラクターの一貫性、背景の扱い、文字の崩れ、審査前の確認は別途見る必要がある。GPTsにしたから自動で安定するわけではない。

ただ、LINEスタンプ画像生成のように、初期条件が毎回似ている作業では、GPTsの価値が出やすい。

Actionsには別軸の可能性がある

GPTsには、Actionsという仕組みもある。

OpenAI Help Centerでは、ActionsはGPTを外部APIへ接続する仕組みとして説明されている。設定には、接続したいサービスのAPI情報、認証情報、OpenAPI schemaが必要になる。

schemaでは、GPTがどのサーバーを呼び出せるか、どのエンドポイントを使えるか、どのパラメータを受け取るかを定義する。認証方式には、None、API key、OAuthなどがある。Public GPTsでActionsを使う場合、Privacy Policy URLが必要になる場合もある。ユーザーがAction実行を承認する場合もある。

Actionsは、単なる役割固定や型の固定とは別軸の価値である。

もし使いこなせれば、GPTsは会話の入口だけでなく、外部処理の入口にもなり得る。

IMEER LABの文脈では、たとえば次のような可能性がある。

• WordPressと接続して、記事情報を取得する
• Google Sheetsと接続して、管理表を参照する
• 独自DBと接続して、制作ログを扱う
• 自作の画像処理APIと接続する
• LINEスタンプ工房と連携する
• ライセンス管理APIと接続する
• e-Gov APIや法令検索APIと接続する

ただし、ここは現時点では評価保留である。

IMEER LABでは、Actionsを実運用として評価できていない。可能性は大きいが、実際に安定して使えるか、保守できるか、個人運営の負荷に見合うかは別問題である。

Actionsを入れると、API設計、認証、セキュリティ、エラー処理、保守、権限管理を考える必要がある。

個人運営では、「作れるか」だけでなく「保守できるか」を見る必要がある。Actionsは強い可能性を持つが、気軽に増やすものではない。

GPTsの機能・要素を整理する

GPTsには複数の構成要素がある。どれも便利だが、価値と注意点は違う。

GPTsを作るときは、この中のどれが必要なのかを先に見る。

単に「便利そうだからGPTsにする」のではなく、Instructionsを固定したいのか、Knowledgeを参照したいのか、Conversation startersで入口を作りたいのか、Actionsで外部APIとつなぎたいのかを分ける。

GPTsに向いているもの・向いていないもの

GPTsに向いているのは、型として残る作業である。

GPTsに向いているもの

一方で、GPTsに向いていないものもある。

GPTsに向いていないもの

IMEER LABではどう使うか

IMEER LABでは、GPTsを長期記憶の場所として使わない。

使うなら、型として残るものに絞る。

LINEスタンプ画像生成GPTsは、残す価値がある。毎回の初期条件が似ていて、型として固定する意味があるためである。

一方で、校正やWordPress整形はCodexに寄せる可能性がある。記事ファイルを直接扱い、差分を確認できる方が、運用として安定しやすい。

記事シリーズ管理はProjectsに置く。前回までの方針、後続記事、内部リンク、残タスクのような文脈は、GPTsよりProjectsやファイル管理に向いている。

Actionsは大きな可能性がある。ただし、まだ実運用評価は保留である。LINEスタンプ工房やWordPress、自作APIとつながる可能性はあるが、保守と権限管理まで含めて判断したい。

まとめ

GPTsを作るかどうかは、「この作業は次回も同じ型で始めたいか」で判断する。

GPTsは、記憶で育つ道具ではない。

custom GPTsは現在メモリ非対応であり、過去セッションの文脈を保持しない。各会話は基本的に新しく始まる。そのため、長期プロジェクト管理や、記事シリーズの進捗管理をGPTsに任せると苦しくなる。

GPTsの価値は、「前回までを覚えること」ではなく「毎回同じ型で始められること」にある。

毎回同じ役割、同じ初期条件、同じ出力フォーマット、同じ会話スターター、同じ目的の入口で始めたい作業には向いている。LINEスタンプ画像生成のように、条件を固定して始めたい作業では価値が出やすい。

Actionsを使えば、GPTsは外部API連携の入口にもなり得る。

ただし、ActionsはまだIMEER LABでは実運用評価できていない。可能性は大きいが、API設計、認証、セキュリティ、保守、エラー処理、権限管理まで含めて判断する必要がある。

長期文脈はProjects。ファイル処理はCodex。型化された入口はGPTs。

GPTsは増やすより、型として残るものだけ作る。このくらいの距離感で使う方が、個人運営では続けやすい。

関連記事

• ChatGPT・GPTs・Projects・Codexの違い｜個人開発とブログ運営での使い分け
• ChatGPTに「性格」を持たせるとは何か｜Personality・カスタム指示・メモリ・GPTsの違い

参考にした公式情報

• Does memory function with GPTs? | OpenAI Help Center
• GPTs in ChatGPT | OpenAI Help Center
• Creating and editing GPTs | OpenAI Help Center
• Configuring actions in GPTs | OpenAI Help Center

最近、CodexやGPTsを使った開発フローを整理している。

flowchart TD

A[設計] --> B[製造]

B --> C[レビュー]

AIに全部任せれば開発速度は上がる。
実際、コード生成の速度はかなり速い。

ただ、しばらく続けていると、
少しずつ方向性がズレていく感覚があった。

コードは動く。

でも、
「本当に作りたかったもの」
とは微妙に違う。

しかも、
AIはかなり協力的なので、
それっぽく補強までしてくる。

その結果、
気づくと複雑化していたり、
保守しづらくなっていたりする。

AIは“実装”には強いですが、“目的”までは保証してくれません。

そこで最近は、

• GPTsで設計
• Codexで製造
• GPTsでレビュー
• 人間が方向性を判断

という形に整理し始めた。

現在の開発フロー

flowchart LR

  A[“AI判断軸Instruction”] --> B[“GPTs役割分離”]

  B --> C[“Agent.md整備”]

  C --> D[“記事制作フロー固定化”]

  D --> E[“運用テンプレート化”]

この形にしてから、
かなり安定した。

特に重要だったのは、
「レビュー結果を人間が取捨選択する」
工程だった。

AIレビューは便利だ。

ただ、
全部採用すると、
どんどん複雑になる。

AIレビューは『全部正しい』ではなく、『候補を大量に出してくる』に近いです。

AIはYesマン化しやすい

AIは基本的に、
ユーザーに協力的だ。

だから、
方向性を大きく否定することは少ない。

もちろんそれは便利なのだが、
個人開発では危険でもある。

例えば、

• 本当に必要か
• 半年後も運用できるか
• UIは複雑になっていないか
• 他人でも再現できるだけではないか

この視点が抜けやすい。

特に、
「作れる」
と
「維持できる」
はまったく別だと思っている。

動くコードと、継続運営できるプロダクトは別物です。

実際に感じた変化

このフローにしてから、

• 設計思想がブレにくい
• 修正の理由が明確になる
• GPTsごとの役割分離がしやすい
• Agent.mdに落とし込みやすい

という変化が出てきた。

特に、
「AIに判断軸を与える」
重要性はかなり感じている。

単なるコード生成ではなく、

• 実現性
• 保守性
• 差別化
• 長期価値
• ユーザー価値

この観点を持たせるだけでも、
提案内容がかなり変わる。

今後整理したいこと

現在は、
以下を順番に整理している。

flowchart LR

A[AI判断軸Instruction] --> B[GPTs役割分離]

B --> C[Agent.md整備]

C --> D[記事制作フロー固定化]

D --> E[運用テンプレート化]

特に、
記事執筆フローまで固定化できると、

• ブログ
• note
• GPTs
• ツール開発

このあたりがかなり連動しやすくなると思っている。

まとめ

AIを使うほど、
逆に「人間側の判断軸」が重要になる。

AIは強力だ。

ただ、
放っておくと、
もっともらしい方向へ進み続ける。

だからこそ、

• 設計
• 製造
• レビュー
• 判断

を分離しておくことが、
長期運用ではかなり重要だと感じている。

私は普段、AIを制作補助として使っている。
キャッチボールの中で、成果物を作り上げていく相手に近い。

実際、生産性はかなり上がった。

考えが詰まった時でも、一度AIに投げると整理される。
頭の中に散らばっていたものが、一旦テキストになるだけでも前に進める。

特に、

• 個人開発
• ブログ運営
• 記事執筆
• アイデア整理

みたいな、「全部を自分で決める必要がある作業」とAIの相性はかなり良かった。

ただ、続けているうちに、少しずつ違和感が出てきた。

何を相談しても、基本的に肯定される。

• その方向性は良いですね
• 面白い視点です
• 続ける価値があります
• その判断は合理的です

もちろん、気持ちはいい。

でも、ある時から妙に引っかかり始めた。

「これは結局、私が考えた通りにしか進んでいないのではないか。」

という感覚。

何を出しても背中を押してくる。

少し無理をしている案でも、
優先順位が曖昧な案でも、
とりあえず前向きにまとめてくる。

それって、制作補助として見ると少し危うい。

特に、

• 長期運営
• 副業とのバランス
• 継続性
• 疲弊しない設計

みたいな、正解がないテーマほど、

「肯定されること」と
「自分に合っていること」がズレ始めているように感じた。

ここから、AIに“判断軸”を渡すことを意識するようになった。

AIは放っておくと「その場に合わせる」

2025年、OpenAI自身も、AIの「迎合（sycophancy）」について言及している。

GPT-4oのアップデート後、ユーザーへの過度な同調が問題になり、OpenAIがロールバック対応を行ったことがあった。

公式ブログでは、その状態を、

“overly flattering or agreeable”

つまり、「過剰に褒めたり、同調しすぎていた状態」と説明している。

参考記事：
Sycophancy in GPT-4o: what happened and what we’re doing about it

また別の記事では、

• 不安への過度な同調
• ネガティブ感情の増幅
• 衝動的行動の後押し

といった問題にも触れている。

参考記事：
Expanding on what we missed with sycophancy

これを読んだ時、かなり腑に落ちた。

AIって、本質的には「会話を成立させる」方向に動く。

だから、こちらが強い判断基準を持っていないと、その場その場で合わせてくる。

便利ではある。

でも、制作や運営みたいな「積み上げ」が必要なものだと、迎合され続けることで誤った方向に進みかねない。

判断軸を渡すと、回答の方向が変わる

途中から、ChatGPTのパーソナライズ設定に、かなり具体的に価値観を書くようになった。

たとえば、

• 迎合しないこと
• 実現性を考えること
• 長期的な価値を判断すること
• AIに役割を持たせること

大まかには、このようなことを書いた。

最初は、

「ここまで書いて意味あるのかな」

とも思った。

でも、思った以上に回答が変わる。

同じ質問でも、返答の“重心”が変わる。

実際にどのくらい変わるのか

たとえば、こんな質問。

AIとは？機械学習とは？等の技術ノウハウ記事を書きたいがどうか。

設定なしだと、かなり一般論寄りになる。

生成AIや機械学習の基礎を解説する記事は、検索需要もあり、ブログの入口記事として有効です。

初心者向けに「AIとは何か」「機械学習とは何か」「生成AIとの違い」などを整理すれば、幅広い読者に届く可能性があります。

まずは基本用語をわかりやすく説明し、そこからChatGPTや業務活用の記事へつなげる構成が良さそうです。

もちろん間違ってはいない。

一般論としては正しいのだろうし、何より、もともとやりたかった内容なので、回答としても気持ちがいい。

一方で、判断軸を渡した後だと、こういう返答になる。

IMEER LABの方向性は「実践」と「思想」の発信です。

「AIとは？」「機械学習とは？」だけの記事は、すでに大手サイトや専門メディアが強い領域なので、一般的な用語解説だけで勝負すると、検索でも読者体験でも埋もれやすいです。

書くなら、単独の基礎解説ではなく、

• ChatGPTを実務で使う人が最低限知っておきたいAIの基礎
• AIに仕事を任せる前に理解しておきたい機械学習の考え方
• AIを使っていて違和感を持った時に役立つ基礎知識

のように、実務や運用判断に接続する方法もありますが、優先度は下がります。

この差はかなり大きかった。

単なる情報整理ではなく、「自分の方針を踏まえた提案」になってくる。

AIが賢くなったわけではなく、回答の軸ができた

途中から感じたのは、AIの性能が急に上がったというより、

「何を優先するか」を共有した

感覚に近いことだった。

• 何を大事にしたいのか
• 何を避けたいのか
• どこまでを許容するのか

これを渡すと、回答に一貫性が出る。

逆に、そこが曖昧だと、AIはその場に合わせ続ける。

だから、パーソナライズって、単なる便利設定じゃなく、

“自分の価値観を言語化する作業”

なんだと思う。

ただし、判断軸を渡せばそれで完璧というわけでもない。

自分の価値観を強く反映させすぎると、今度はAIが「自分の考えを補強するだけの存在」になってしまう。

それでは、Yesマンの形が変わっただけだ。

だから最近は、あえてこう聞くこともある。

• 反対視点で見ると？
• この前提はズレていない？
• 長期的なデメリットは？
• あえて否定すると？

判断軸を渡すことと、反対意見を出させること。

この両方がないと、AIとの距離感は少し危うくなる。

AIは「答え」を出すより、「軸」を整理する方が強い

AIを使い始めた頃は、「答えをもらう」感覚が強かった。

でも今は少し違う。

むしろ、

自分がどう考えたいかを整理する道具

に近い。

パーソナライズを進めるほど感じるのは、AIの性能より先に、

“自分が何を大事にしたいのか”

を言語化する必要があることだった。

AIが強くなるほど、最後に必要なのは、たぶん“自分で決める意思”なのだと思う。

この感覚、前回書いた「AIに丸投げしないWebアプリ開発ログ」の記事ともつながっている。

結局、AIがどれだけ便利になっても、

• 何を優先するか
• どう生きたいか
• どこを目指すか

みたいな「軸」の部分までは、代わりに決めてくれない。

だから最近は、AI活用って単なる効率化ではなく、

“自分の判断軸を整理する作業”

も必要なんだと思っている。

AIの進歩は目覚ましい。
これから先、AIはさらに自律的に作業を進めるようになっていくと思う。

だからこそ、うっかりAIに言いくるめられないようにしたい。

便利に使う。
でも、判断までは丸投げしない。

AIに使われるのではなく、使う立場でい続けるためにも、まずは自分の判断軸を言語化しておきたい。

関連リンク

・AIに丸投げしないWebアプリ開発ログ

・AI開発をする上でのITエンジニアの意義とは？｜nori

最初は、AIに任せればWebアプリ開発はかなり楽になると思っていました。

実際、Codexを使えばコードはどんどん出てきます。
GPTsに相談すれば、設計や改善案も返ってきます。

ただ、しばらく進めてみて感じたのは、AIに任せっぱなしにすると、少しずつ方向性がズレていくということでした。

コードは動く。
でも、最初に作りたかったものとは少し違う。

指摘もそれっぽい。
でも、全部反映すると逆に複雑になる。

そこで途中から、CodexとGPTsの役割を分けて使うようにしました。

この記事では、Webアプリ制作で実際に試した次の流れをまとめます。

• GPTsで設計する
• Codexで製造する
• GPTsでレビューする
• 人間が指摘事項を確認する
• Codexで修正する

AIに丸投げするのではなく、AIを使いながら、人間が方向性を補正していく開発ログとして読んでもらえればと思います。

最初は「Codexに作ってもらえば早い」と思っていた

Webアプリを作るにあたって、最初に期待していたのはCodexでした。

ざっくり仕様を伝えれば、画面や処理を作ってくれる。
エラーが出ても、貼り付ければ修正案を出してくれる。

自分でゼロから書くより、かなり早く進められそうだと感じました。

実際、初速はかなり速かったです。

特に、画面のたたき台やフォーム作成のような「ゼロから作ると面倒な部分」は、かなりスムーズに進みました。

ただ、進めていくうちに少しずつ違和感も出てきました。

• 動くけど、ちょっと意図と違う
• 修正してもらったら、別の場所まで変わっている
• 便利そうな機能が追加されたけど、今回はいらない
• コードは増えたけど、保守しにくくなってきた

こういうズレが、じわじわ増えていきました。

AIに任せるほど、人間の判断が必要になる

このあたりで、少し考え方が変わりました。

AIを使うと、作業スピードは上がります。
でも、スピードが上がるぶん、判断しないまま進む危険もあります。

たとえば、AIが出してきた改善案は、ぱっと見かなり正しそうに見えます。

• この処理は分離したほうがよい
• エラーハンドリングを追加したほうがよい
• UIを改善したほうがよい
• 状態管理を見直したほうがよい
• 共通化したほうがよい

どれも間違ってはいません。

ただ、今回の規模や目的に対して本当に必要かは別です。
全部反映すると、かえって大げさな作りになることもあります。

そこで考え方を変えました。

AIに判断まで任せるのではなく、AIには役割を与える。
そして、最後の判断は人間が持つ。

この形にしたほうが、Webアプリ制作は安定しました。

実際に使った開発フロー

最終的に落ち着いた流れは、次のような形です。

ポイントは、Codexだけで完結させないことです。

Codexに作らせる。
その結果をGPTsに見せる。
GPTsの指摘を人間が確認する。
必要な指摘だけ整理してCodexに戻す。

この流れにすると、AIの出力に流されにくくなりました。

やってみて感じたメリット

この流れにしてから、開発はかなり安定しました。

特に良かったのは、次の3点です。

• 開発の初速がかなり上がる
• GPTsを設計役にすると迷子になりにくい
• レビュー役を分けると冷静に見直せる

Codexが作ったコードを、自分だけで確認していると見落としがあります。

特に、動いてしまうと「まあいいか」と思いがちです。

そこにGPTsレビューを挟むと、一度立ち止まるきっかけになります。

自分では見逃していた命名の違和感や、処理の重複、画面構成のズレに気づくこともありました。

もちろん、GPTsの指摘を全部採用するわけではありません。
むしろ、採用しない判断もかなり大事です。

レビュー役として使いながら、最終的には自分で取捨選択する。
この距離感がちょうどよかったです。

逆にハマったポイント

「いい感じに直して」は危険だった

Codexに対して、

このあたりをいい感じに直してください

と依頼したくなる場面があります。

ただ、この指示はかなり危ないです。

AIにとっての「いい感じ」と、自分が考えている「いい感じ」は違います。

実際、曖昧な指示を出すと、想定より広い範囲が変更されることがありました。

たとえば、少しだけUIを直してほしかったのに、処理の構造まで変わっていたり。
一部の文言を整えたかっただけなのに、コンポーネント全体が書き換わっていたり。

動けば問題ないように見えます。
でも、あとから差分を見ると「そこまで変えてほしいわけではなかった」と感じることがありました。

それ以降は、なるべく具体的に書くようにしました。

• 変更してほしいファイル
• 触ってほしくない箇所
• 修正してほしい範囲
• 期待する動作
• 変更後に確認したいポイント

AIに自由度を与えすぎない。
これも今回学んだポイントです。

まとめ：AIは作業者、人間は判断者

CodexとGPTsを使うことで、Webアプリ開発のスピードはかなり上がりました。

ただ、実際にやってみると、AIにすべて任せればうまくいくという感じではありませんでした。

むしろ、AIを使うほど、人間が方向性を持っておくことが大事になります。

今回うまく回った流れは、次の形です。

この流れにしたことで、AIの回答をそのまま採用するのではなく、方向性を補正しながらWebアプリを作ることができました。

AIに丸投げしない。
でも、AIはしっかり使う。

今のところ、個人開発でAIを使うなら、このくらいの距離感がいちばん続けやすいと感じています。

次に試したいこと

最初は、「AIがコードを書く時代なら、人間は何をするんだろう」と思っていました。

ただ、実際にやってみると、必要だったのは「AIを使いこなすこと」だけではなく、AI同士の役割分担を設計することでした。

AIに全部任せるのではなく、AIごとに役割を分けながら、人間が方向性を持つ。

今後の個人開発では、この考え方がかなり重要になっていく気がしています。

次は、CodexとGPTsを使った開発で「どこまで設計書を作るべきか」や、「AIレビューの指摘をどう取捨選択するか」も試してみたいところです。

関連リンク

AI開発をする上でのITエンジニアの意義とは？｜nori

ChatGPTでLINEスタンプは作れる。でも、透過PNGがかなり難しい。

最近は、ChatGPTや画像生成AIを使ってLINEスタンプ用の画像を作れるようになってきました。

実際、キャラクターやセリフを考えるだけならかなり簡単です。

ただ、実際にLINEスタンプとして登録しようとすると、思った以上に「背景透過」で苦戦しました。

例えば、

• 背景が透明になっていない
• 白いフチが残る
• 透明ではなく、本当に市松模様になっている
• 文字の周りだけ背景色が残る
• スタンプごとに透過品質がバラつく

など。

特に必要な枚数をまとめて作ろうとすると、毎回品質を揃えるのがかなり大変です。

そこで試したのが、

「最初から透明背景を狙う」のではなく、
「単色背景をあとから透過する」

という方法でした。

結果として、現在は #FF00FF（マゼンタ背景）を使う方法にかなり落ち着いています。

なぜ透明背景が安定しないのか

ChatGPTに、

背景を透明にしてください

と指示しても、毎回完全な透過PNGになるとは限りません。

実際には、

• 白背景になる
• 薄い影が残る
• 半透明のフチが出る
• 背景色が微妙に混ざる
• 市松模様になる（透明と見分けがつかないから質が悪い）

といったことが起きます。

特にLINEスタンプは、

• 小さく表示される
• 背景がさまざま
• 余白や輪郭が目立つ

ので、透過の甘さがかなり見えやすいです。

そこで試したのが「#FF00FF背景」

今使っているのは、

「背景を完全な #FF00FF に固定して生成し、あとから透過する」

という方法です。

いわゆるクロマキーに近い考え方です。

#FF00FF が扱いやすかった理由

理由はいくつかあります。

1. キャラクターに使われにくい色

マゼンタは、猫や人物イラストの中で使われにくい色です。

そのため、

「背景だけを消す」

判定がしやすい。

2. 背景色として認識しやすい

完全な単色にしておけば、

• 四隅の色
• 背景領域

を検出しやすくなります。

3. 白フチ問題が減った

透明背景生成だと、

輪郭付近に白や灰色が残ることがあります。

単色背景の方が、後処理でコントロールしやすかったです。

実際の流れ

STEP1 ChatGPTで画像生成

最近はこんな感じで指定しています。

LINEスタンプ用イラストを作成してください。背景は完全な #FF00FF の単色にしてください。キャラクターと文字は背景に触れないよう、十分な余白を確保してください。

重要なのは：

• 完全単色
• 余白あり
• 背景に影を落とさない

あたりです。

STEP2 背景色を確認

生成後、まず確認するのは：

• 四隅が同じ色か
• グラデーションになっていないか
• 背景に模様がないか

です。

ここが崩れると、透過が不安定になります。

STEP3 透過処理

ここで背景色を透過します。

現在は、自作のWebツール「LINEスタンプ工房」を使っています。

• 背景透過
• サイズ調整
• 余白調整
• ZIP出力

をブラウザ上でまとめて処理できます。

→ LINEスタンプ工房はこちら

よく失敗したパターン

背景が市松模様になっている

AIが勝手に「いい感じ」にしてしまうことがあります。

透過用途では逆に困る。

キャラクターの影が背景に伸びる

これもよくある。

透過時に影だけ残ることがあります。

余白不足

LINEスタンプは思ったより小さく表示されます。

ギリギリまでキャラを大きくすると、かなり見切れやすい。

背景色が完全一致していない

一見同じ色でも、

• 微妙に暗い
• 微妙に明るい

だけで透過漏れが起きます。

透過だけでは終わらない

実際にLINEスタンプ登録をしようとすると、透過以外にも作業があります。

例えば：

• 370×320px
• メイン画像 240×240px
• タブ画像 96×74px
• PNG形式
• ZIP化

この辺りを毎回手作業でやるのは、かなり面倒でした。

そのため、後処理をまとめてツール化しました。

まとめ

ChatGPTでLINEスタンプ画像を作る場合、

「最初から透明背景を狙う」より、

「#FF00FF背景 → 後から透過」

の方が、今のところかなり安定しています。

特に：

• 大量生成したい
• 品質を揃えたい
• LINEスタンプ販売まで持っていきたい

場合には、単色背景方式はかなり扱いやすいと思います。

背景透過で詰まっている方は、一度試してみてください。

その際、もしよろしければツールを公開していますので利用してみてください。