たしかに、見た目はフォルダに近い。

ブログ用のチャット。
LINEスタンプ用のチャット。
AI活用記事用のチャット。
仕事の整理用のチャット。

そういうものをまとめておく場所として見ると、Projectsは「チャットの分類箱」に見える。

ただ、実際に使ってみると、それだけでは少し足りなかった。

Projectsは、単なるフォルダというより、そのテーマの前提、資料、方針、判断軸を置いておく作業部屋に近い。

Projectsは何をするための機能なのか

OpenAIの公式ヘルプでは、Projectsは長く続く作業に関係するものを一か所にまとめるワークスペースとして説明されている。

具体的には、Project内に以下をまとめられる。

• 関連するチャット
• 参照したいファイル
• Projectごとの指示
• そのテーマで使う文脈や前提

つまり、Projectsはチャットを入れるだけの箱ではない。

チャット、ファイル、指示をまとめて、そのテーマで作業を続けやすくするための場所だ。

ここが、通常チャットとの大きな違いになる。

通常チャットは、その場の相談に向いている。

「この文章を直して」
「このエラーの意味を教えて」
「このアイデアを整理して」

このくらいなら、通常チャットで十分だ。

一方で、何度も続くテーマになると、毎回前提を説明するのが面倒になる。

このブログはどういう方針なのか。
このシリーズでは何を扱ってきたのか。
このツールは何のために作ったのか。
このProjectでは何をやらないことにしているのか。

そういう前提を置いておく場所として、Projectsが効いてくる。

フォルダではなく「作業部屋」と考える

Projectsをフォルダだと思うと、使い方は整理で止まりやすい。

チャットを分類する。
後から見つけやすくする。
テーマごとにまとめる。

もちろん、それも便利だ。

ただ、それだけだと少しもったいない。

Projectsは、チャットをしまう箱というより、そのテーマで作業するための部屋として考えた方が使いやすい。

たとえば、ブログ運営のProjectなら、そこにはブログ運営の前提がある。

どんな読者に向けて書くのか。
どんな文体にするのか。
どんな表現を避けるのか。
どの記事シリーズとつながるのか。
noteや無料ツールへの導線をどう考えるのか。

こういう前提をProject側に置いておく。

すると、毎回ゼロから説明しなくても、「このProjectではこういう方針で考える」という状態を作りやすくなる。

Projectsは、チャットを片付ける場所というより、毎回同じ説明をしなくて済むようにする場所だと考えると分かりやすい。

通常チャットとの違い

通常チャットは、単発の相談に向いている。

思いついたことを聞く。
文章を少し直す。
軽く壁打ちする。
調べたいことを聞く。

その場で終わるなら、通常チャットで十分だ。

逆に、通常チャットで扱い続けると面倒になるものがある。

たとえば、記事シリーズ。

第1弾で何を書いたのか。
第2弾で何を整理したのか。
第3弾では何を言ったのか。
次の記事でどこまで踏み込むのか。

これを毎回説明するのは手間になる。

Projectsに入れておけば、そのテーマのチャットや資料を同じ場所に置ける。

通常チャットが「その場の机」だとすると、Projectsは「資料を置いた作業部屋」に近い。

GPTsとの違い

GPTsとの違いも、少しややこしい。

私の感覚では、GPTsは決まった用途の入口だ。

たとえば、以下のようなものはGPTsに向いている。

• 記事レビュー専用GPT
• LINEスタンプ案を出すGPT
• WordPress投稿前チェックGPT
• 企画整理専用GPT

「この型で処理してほしい」
「この手順でレビューしてほしい」
「この出力形式で返してほしい」

こういう作業はGPTsが向いている。

一方で、Projectsはもう少し広い。

Projectsは、特定の作業手順というより、そのテーマ全体の文脈を置く場所だ。

たとえば「AI活用記事シリーズ」というProjectなら、そこでは記事レビューだけではなく、複数の作業が発生する。

次の記事テーマを考える。
過去記事とのつながりを見る。
公式情報を整理する。
アイキャッチ案を考える。
noteとの切り分けを考える。
やらない記事を判断する。

これは、ひとつのGPTsに閉じ込めるより、Projectとして扱う方が自然だ。

GPTsは「型」。
Projectsは「作業部屋」。

そう考えると、かなり分かりやすくなる。

カスタム指示との違い

カスタム指示は、ChatGPT全体に効かせる基本姿勢だ。

たとえば私の場合なら、以下のような方針を入れておきたい。

• ただ肯定しない
• 論点を整理する
• 実現性や保守性を見る
• やらない判断も出す
• 最終判断は自分がする前提で、判断材料を出す

これは、どのチャットでも効いてほしい基本姿勢になる。

一方で、Projectsに入れる指示は、もっとテーマ寄りだ。

ブログ運営Projectなら、ブログの方針。
LINEスタンプProjectなら、スタンプ制作の前提。
AI記事シリーズProjectなら、シリーズ全体の狙い。

つまり、こう分けるとよい。

カスタム指示は、自分全体の基本姿勢。
Projectsの指示は、そのテーマ専用の作業ルール。

なお、OpenAIの公式ヘルプでは、Projectの指示はそのProject内に適用され、グローバルなカスタム指示より優先されると説明されている。

だからこそ、Projectの指示には「そのテーマでだけ守ってほしいこと」を書くのがよい。

Projectsに向いているもの

Projectsに向いているのは、1回で終わらないテーマだ。

たとえば、以下のようなものが向いている。

• ブログ運営
• 記事シリーズ
• LINEスタンプ制作
• 無料ツールの公開方針
• 副収入計画
• 長期の調査
• 継続的な学習
• 仕事の論点整理
• 個人開発の方針整理

ポイントは、何度も同じ前提を使うかどうかだ。

一度聞いて終わるなら、通常チャットで十分。

でも、毎回同じ背景を説明しているなら、Projectsに分けた方がよい。

Projectsに入れない方がいいもの

逆に、何でもProjectsに入れればよいわけではない。

たとえば、以下のようなものは通常チャットで十分だ。

• 一回だけの質問
• 軽い雑談
• すぐ終わる文章修正
• 単発の調べもの
• テーマ化するほどではない思いつき

Projectsを増やしすぎると、今度はProjects自体が散らかる。

フォルダを増やしすぎるのと同じだ。

Projectsは便利だが、細かく分けすぎると管理対象が増える。

なので、私は「長く続くテーマ」だけProjectにするくらいでよいと思っている。

Projectを作るか迷ったら、「次回も同じ前提を使うか」で見ると判断しやすい。一回で終わる話なら、通常チャットの方が軽い。

私ならこう分ける

私の使い方なら、ざっくりこう分ける。

ブログ運営はProjects。
AI記事シリーズもProjects。
LINEスタンプ工房の運営方針もProjects。
副収入計画もProjects。

一方で、単発のタイトル案や、ちょっとした文章修正は通常チャットで十分だ。

記事レビューのように、毎回同じ観点で見たいものはGPTsにする。

コードやファイルを実際に直す作業はCodex側に寄せる。

この分け方にしておくと、ChatGPT側で考えることと、Codex側で実装することが混ざりにくい。

ただし、この記事ではCodexの話は深掘りしない。

ここで大事なのは、Projectsを「ChatGPT内でテーマを継続して扱う場所」として見ることだ。

IMEER LAB運営でのProjects例

たとえば、IMEER LAB運営のProjectを作るなら、Projectの指示にはこう書く。

このProjectでは、IMEER LABのブログ運営、note展開、LINEスタンプ、GPTs活用、無料ツール導線を扱います。 具体的な実装作業ではなく、企画、導線、判断軸、優先順位、やらない判断を中心に整理してください。 記事や企画では、以下を重視してください。 - 技術者の作業メモ感を残す - 実体験と判断材料を入れる - 成功談に整えすぎない - 迷ったこと、やめたこと、判断を変えたことも価値として扱う - 個人運営で維持できるかを見る - 半年後にも意味が残るかを見る - ブログ、note、無料ツール、GPTsの導線につながるかを見る 実装詳細、Git操作、API設計、コード修正、テスト設計は別Projectに切り分けてください。

このように書いておくと、そのProject内では「これは運営方針の話」「これは開発室に切り分ける話」のように整理しやすくなる。

単なるフォルダではなく、Projectごとに判断軸を持たせるイメージだ。

Projectsには何を書くべきか

Projectsの指示には、細かい作業手順を詰め込みすぎない方がよい。

毎回変わる手順よりも、毎回変えたくない前提を書く。

たとえば、ブログ用Projectなら以下のような内容が向いている。

• 誰に向けて書くか
• どんな文体にするか
• どんな表現を避けるか
• どの記事シリーズとつながるか
• どこまで技術的に踏み込むか
• noteや無料ツールへの導線をどう扱うか
• 何をこのProjectでは扱わないか

開発用Projectなら、以下のような内容が向いている。

• どのリポジトリを扱うか
• 優先する設計方針
• テスト方針
• 触ってよい範囲
• 触らない方がよい範囲
• 判断に迷ったときの優先順位

副収入計画なら、以下のような内容が向いている。

• 何を優先するか
• 何をやらないか
• 収益化より先に整えるもの
• 無料公開するもの
• 有料化を検討するもの
• 続けられる作業量

Projectsに置くべきなのは、毎回説明するのが面倒なものだ。

忘れられると話がずれるもの。
そのテーマでは常に守ってほしいもの。
判断に迷ったときに戻る基準。

そういうものを置いておくと、Projectsが作業部屋として機能しやすくなる。

まとめ：続くテーマはProjectsに置く

Projectsは、単なるフォルダではない。

もちろん、チャットを整理する場所としても使える。

でも、それだけでは少しもったいない。

Projectsは、長く続くテーマの前提、資料、指示、チャットをまとめておく作業部屋として使うと便利だ。

通常チャットは、その場の相談。
GPTsは、決まった用途の入口。
カスタム指示は、自分全体の基本姿勢。
Projectsは、テーマごとの作業部屋。

この分け方をしておくと、ChatGPTの使い方がかなり整理される。

特に、ブログ運営、記事シリーズ、個人開発、副収入計画のように、何度も同じテーマを扱う場合はProjectsが向いている。

フォルダとして使うだけではなく、そのテーマの作業部屋として使う。

Projectsは、そう考えた方がしっくりきた。

編集者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

ロコっぽく話してほしい。やわらかく返してほしい。辛口にレビューしてほしい。技術者っぽく整理してほしい。こうした調整は、たしかにChatGPTの使い勝手に影響する。

最初は、もっと柔らかく返してほしい、もっと率直に言ってほしい、ブログ編集者っぽく見てほしい、くらいの話だと思っていた。

ただ、実際に使ってみると、口調を変えるだけでは足りなかった。

文体は整っていても、判断基準が違う。やさしく返してくれるけれど、記事として弱いところを指摘してくれない。逆に辛口にはなるが、何を基準に辛口なのかが曖昧になる。

そこで、「性格」と一言で呼んでいたものを分解して考える必要が出てきた。

ただし、「性格」という言葉を広く使いすぎると混乱する。

OpenAIには、Personality、カスタム指示、メモリ、GPTs、Projects、Codex / AGENTS.mdなど、AIの返答や作業に影響する複数の仕組みがある。どれも「AIを自分向けに調整するもの」に見えるが、実際には影響する範囲が違う。

この記事では、公式情報をもとに、話し方、指示、記憶、役割、文脈、開発ルールを分けて整理する。

まず「性格」を雑に使わない

OpenAI Help Centerでは、ChatGPTのPersonalityは、ChatGPTが返答するときのスタイルやトーンを調整するものとして説明されている。

つまり、Personalityは話し方に関わる。

たとえば、簡潔に答える、より専門的に答える、親しみやすく答える、率直に答える、といった返答スタイルに影響する。

ここで重要なのは、Personalityを変えても、ChatGPTができることや安全ルールが変わるわけではない点である。

また、メール文、コード、SNS投稿、履歴書など、具体的な成果物を求める依頼では、選択中のPersonalityよりも、ユーザーの指示や文脈に合った出力が優先される。たとえば、やわらかいPersonalityを選んでいても、コードを書いてほしいと頼めば、コードは機能する形で出る。

Personalityは、機能追加ではなく「話し方の基本設定」に近い。

カスタム指示は、全体方針を渡す場所

カスタム指示は、ChatGPTに考慮してほしい自分の前提や応答方針を共有する設定である。

OpenAI Help Centerでは、カスタム指示はChatGPTの返答で考慮してほしいことを共有でき、基本的に全チャットへ適用されると説明されている。

IMEER LABで考えると、たとえば次のような方針を置く場所に近い。

• 日本語は常体で書く
• 技術者の作業メモに近い文体にする
• 過剰なSEO記事っぽさを避ける
• 表で整理できるものは表にする
• 仕様変更があり得るものは断定しすぎない

ただし、カスタム指示も万能ではない。

すべての成果物にそのまま出るとは限らない。会話ごとの指示や、求めている成果物の性質が優先されることもある。

カスタム指示は「全体方針を渡す場所」と考えると扱いやすい。

メモリは、継続的な個人文脈を反映する仕組み

メモリは、ChatGPTが過去の会話から得た有用な情報を、今後の応答に反映する仕組みである。

OpenAI Help Centerでは、ChatGPTは好みや関心などの役立つ文脈をチャット間で記憶し、より個人化された応答に使えると説明されている。

たとえば、次のようなものはメモリに向いている。

• IMEER LABという個人ブログを運営している
• Excel、AI、自動化、WordPress、個人開発を扱っている
• 常体の文体を好む
• AI量産記事っぽい文章を避けたい

一方で、メモリは明示的なプロジェクト管理の場所ではない。

OpenAI Help Centerでも、メモリは高レベルの好みや詳細を覚えるためのもので、正確なテンプレートや長い文章ブロックの保存先としては頼らない方がよいと説明されている。

つまり、メモリは「個人文脈を反映する仕組み」であって、「記事シリーズの管理表」ではない。

GPTsは、目的別の役割を固定する場所

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

公式FAQでは、GPTsはInstructions、Knowledge、Capabilitiesを組み合わせて、目的に合ったChatGPTを作れると説明されている。

IMEER LABで使うなら、GPTsは次のような役割に向く。

• 編集者GPT
• 校正GPT
• 技術レビューGPT
• WordPress整形GPT

ここで固定するのは、単なる口調ではない。何を見るか、どの観点で返すか、どこを注意するかを固定する。

たとえば、編集者GPTなら「常体で書く」「実作業感を残す」「AI量産SEO記事っぽさを避ける」「ロココメントを入れすぎない」といった判断軸を持たせる。

ただし、GPTsは長期記憶の場所ではない。

公式FAQでは、GPTsは保存メモリ、カスタム指示、過去会話を使わず、各会話は新しく始まると説明されている。したがって、GPTsは「目的別の役割固定」に使い、長期テーマの文脈管理はProjectsに分ける方がよい。

Projectsは、長期テーマの文脈をまとめる場所

Projectsは、チャット、ファイル、プロジェクト固有の指示をまとめる作業場所である。

公式ヘルプでは、Project Memoryにより、同じProject内の会話やファイルの文脈を使えると説明されている。Project-only memoryを選ぶと、保存メモリやProject外の会話を参照せず、同じProject内に文脈を閉じられる。

記事シリーズ、長期調査、個人開発の設計メモにはProjectsが向いている。

ただし、Projectsも万能ではない。何でも入れると文脈が濁る。Projectsは「長期テーマの置き場」であって、「全部の会話を保存する箱」ではない。

Codex / AGENTS.mdは、開発ルールを置く場所

Codexは、コードを読み、編集し、テストやリンターなどのコマンドを実行できる開発向けエージェントである。

OpenAIのCodex紹介では、AGENTS.mdをリポジトリに置くことで、コードベースの読み方、テストコマンド、プロジェクト標準の守り方などをCodexに伝えられると説明されている。

ここで重要なのは、Codexに必要なのは「性格」ではなく「開発ルール」だという点である。

丁寧に話すCodexよりも、テスト手順を知っているCodexの方が実務では安定する。どのコマンドを実行するか。どのファイルを触るか。どの差分を確認するか。そういうルールをAGENTS.mdやREADMEに置く。

6つを比較する

この表を見ると、「AIに性格を持たせる」という言葉だけでは足りないことが分かる。

Personalityは話し方。カスタム指示は全体方針。メモリは継続的な個人文脈。GPTsは目的別の役割固定。Projectsは長期テーマの文脈管理。Codex / AGENTS.mdは開発作業のルール固定である。

公式情報としてはここまでで十分である。問題は、個人運営の中でどこに何を置くかである。

口調を変えるだけならPersonalityで足りることがある。けれど、毎回同じ観点で見る、同じ基準で直す、同じ手順で確認するなら、指示やルールの置き場所を分けた方が安定する。

IMEER LABではどう分けるか

IMEER LABでは、次のように分けるのが扱いやすい。

この分け方にしておくと、「AIにどういう性格を持たせるか」ではなく、「どの判断をどこに置くか」で考えられる。

ここでは概念整理にとどめる。実際にGPTsへどの判断軸を持たせ、どれを持たせないかは、次の記事で具体的に扱う。

まとめ

ChatGPTに「性格」を持たせると言っても、実際には複数の単位がある。

Personalityは話し方を調整する。カスタム指示は全体方針を渡す。メモリは継続的な個人文脈を反映する。GPTsは目的別の役割を固定する。Projectsは長期テーマの文脈をまとめる。Codex / AGENTS.mdは開発ルールを置く。

重要なのは、話し方と判断軸を混ぜないことだ。

性格、指示、記憶、役割を分けて考えると、GPTsを何でも作ればよいわけではないことが見えてくる。次の記事では、個人運営でGPTsを増やしすぎない方がよい理由を整理する。

関連記事

• ChatGPT・GPTs・Projects・Codexの違い｜個人開発とブログ運営での使い分け
• GPTsを増やしすぎない方がいい理由｜個人運営でAI役割分担が崩れるポイント

参考にした公式情報

• Customizing Your ChatGPT Personality | OpenAI Help Center
• ChatGPT Custom Instructions | OpenAI Help Center
• Memory FAQ | OpenAI Help Center
• GPTs in ChatGPT | OpenAI Help Center
• Projects in ChatGPT | OpenAI Help Center
• Introducing Codex | OpenAI

通常のChatGPTだけでなく、GPTs、Projects、Codexもある。どれもAIに相談したり、作業を進めたりするためのものではあるが、実際に使い始めると役割が違う。

ここを整理しないまま使うと、便利なはずなのに作業場所が散る。

GPTsを作ったけれど使わなくなる。Projectsに何でも入れて文脈が濁る。Codexに任せるべき作業と、ChatGPTで相談すれば十分な作業が混ざる。ブログ記事では、AIに任せる部分と人間が見る部分も曖昧になりやすい。

この記事では、OpenAI公式情報をもとに、ChatGPT、GPTs、Projects、Codexの違いを整理する。

細かい料金、利用上限、画面名、モデル名は変わる可能性があるため、ここでは「何のために使うものか」「個人開発やブログ運営でどう分けるか」を中心に見る。

この記事で扱う範囲

この記事で扱うのは、次の4つである。

• ChatGPT
• GPTs
• Projects
• Codex

Personality、カスタム指示、メモリの詳しい違いは、次の記事で分けて扱う。GPTsを増やしすぎない実運用の話も、この記事では深掘りしない。

まずは、OpenAI機能の全体地図を作る。

ChatGPTは、その場の相談と壁打ちに向く

OpenAI Help Centerでは、ChatGPTはブレインストーミング、文章作成、学習、計画、数学、コーディング、画像やファイルの分析など、日常的なタスクに使えるAIアシスタントとして説明されている。

実際の使い方としては、ChatGPTは一番入口に近い。

たとえば、記事テーマを相談する。Excel関数の考え方を確認する。VBAのエラー原因を聞く。WordPressの記事構成をざっくり壁打ちする。こういう「まだ作業の形が固まっていない段階」では、通常のChatGPTが使いやすい。

同じ会話内であれば、前後のやり取りを踏まえて続けられる。追加質問もしやすい。調べたいことがあればWeb検索を使える場合もある。

ただし、ChatGPTだけで長期運用を組もうとすると、少し不安定になる。

毎回同じ編集方針でレビューしてほしい。毎回同じブログの前提を踏まえてほしい。記事シリーズ全体の流れを維持してほしい。そういう用途では、通常のChatGPTだけに頼ると、会話ごとに説明し直す手間が出る。

ChatGPTは万能の作業場というより、その場の相談、壁打ち、初期整理に向いている。

GPTsは、目的別の役割固定に向く

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

OpenAI Help Centerでは、GPTsはInstructions、Knowledge、Capabilitiesなどを組み合わせて、目的に合ったChatGPT体験を作れるものとして説明されている。たとえば、指示で振る舞いや境界を決め、Knowledgeとして参照ファイルを持たせ、Web検索や画像生成などの機能を選べる。

ブログ運営で考えると、GPTsは役割固定に向いている。

たとえば、次のような使い方である。

• IMEER LAB編集者GPT
• 技術レビューGPT
• WordPress整形GPT
• 記事タイトル案レビューGPT

毎回「あなたはIMEER LABの編集者です。常体で、AI量産SEO記事っぽさを避け、実作業感を残してください」と説明する代わりに、GPT側にあらかじめ役割を持たせる。

ただし、GPTsは長期プロジェクトの履歴を持ち続ける場所ではない。

公式FAQでは、GPTsは保存メモリ、カスタム指示、過去会話を使わず、各会話は新しく始まると説明されている。つまり、GPTsは「記事シリーズ全体の履歴を管理する場所」ではなく、「目的別の役割を固定する場所」と見た方がよい。

Projectsは、長期テーマの文脈管理に向く

Projectsは、長期的な取り組みに関係するチャット、ファイル、指示をまとめる作業場所である。

OpenAI Help Centerでは、Projectsは長期作業のためのワークスペースとして説明されている。チャット、ファイル、プロジェクト固有の指示をまとめられ、執筆、調査、計画のような繰り返し発生する作業に向く。

ブログ運営では、Projectsは記事シリーズ単位で使いやすい。

たとえば、今回のような「OpenAI機能の使い分け」シリーズであれば、次のようなものを同じProjectに置ける。

• 公式情報の確認メモ
• 比較表
• 第一弾記事の構成案
• 後続記事案
• 内部リンク計画
• IMEER LABの編集方針

通常のChatGPTで毎回説明し直すより、Projectsにまとまっていた方が戻りやすい。記事を1本で終わらせず、シリーズとして育てるなら、Projectsは相性がよい。

ただし、Projectsも万能の保存場所ではない。

何でも入れると文脈が濁る。ブログ全体、個人開発、noteの思想メモ、WordPress設定、LINEスタンプ工房の話を全部同じProjectに入れると、AIが参照する文脈も散る。

Projectsは、記事シリーズ、開発プロジェクト、運用改善テーマくらいの単位で分けるのが扱いやすい。

Codexは、コード作業・レビュー・テスト導線に向く

Codexは、コード作業に特化したAIエージェントである。

OpenAIのCodex紹介では、Codexはコードベースを読み、ファイルを編集し、テスト、リンター、型チェックなどのコマンドを実行できると説明されている。作業後にはログやテスト出力を根拠として確認し、さらに修正を依頼したり、Pull Requestにつなげたりできる。

ChatGPTでもコード相談はできる。

しかし、既存ファイルを読んで、必要な箇所を直し、テストを実行し、差分を確認するような作業になると、ChatGPTよりCodexの方が向いている。

たとえば、次のような作業である。

• Webアプリのバグ修正
• 既存コードのリファクタ
• テスト追加
• WordPress向けMarkdown整形スクリプトの改善
• LINEスタンプ工房の機能追加
• 差分レビュー

Codexは自然文で相談するだけの場所ではなく、作業ディレクトリやリポジトリを前提に動く。だからこそ、任せる前の準備が重要になる。

テストコマンドがあるか。依存関係が再現できるか。変更してよいファイル範囲が明確か。レビューすべき差分が見えるか。こうした条件が整っているほど、Codexは使いやすくなる。

ただし、Codexを使えば自動的に安全な開発フローが完成するわけではない。テストがないプロジェクトでは、Codexも確認基準を持ちにくい。個人開発で使う場合は、小さな変更単位に分け、差分を確認し、人間側で最終判断する前提にした方がよい。

コードを直せることと、運用に耐えることは別である。特に公開中のWebアプリ、WordPress運用、記事生成スクリプトに関わる変更では、Codexの作業結果をそのまま通すのではなく、テスト結果と差分を見てから反映する。

4つを比較する

この表で見ると、4つは単純な上位下位ではない。

ChatGPTは入口。GPTsは役割。Projectsは文脈。Codexは実装作業。このくらいに分けると、使い分けが見えやすくなる。

ここまでが公式情報ベースの整理である。

ここからは、IMEER LABで実際にブログ運営や個人開発へ当てはめる場合の使い分けとして考える。

IMEER LABではこう使い分ける

IMEER LABでは、次のように分けるのが現実的だと考えている。

特に大事なのは、最後の人間の部分である。

AIは文章を整えたり、構成を出したり、コードを直したりできる。しかし、実際に何が面倒だったか、なぜその判断に変えたか、どこで違和感が出たかは、本人が見ないと弱くなる。

技術記事ではAIに構成と本文のたたき台を作らせてもよい。ただし、温度記事では「何に引っかかったか」「どこでやめたか」「なぜ続けられる設計を優先したか」は、人間側が追記する必要がある。

機能を増やすより、戻る場所を決めておく方が効く。あとで再開できる形になっていないと、便利なはずのAI運用も少しずつ散らかる。

まとめ

ChatGPT、GPTs、Projects、Codexは、どれもAIを使った作業を助けるものだが、役割は違う。

ChatGPTは、その場の相談や壁打ちに向いている。GPTsは、編集者や校正役のような固定役割に向いている。Projectsは、記事シリーズや長期テーマの文脈管理に向いている。Codexは、コードを読み、編集し、テストする開発作業に向いている。

個人運営では、全部を一つの場所で済ませようとするより、使う場所を分けた方が続けやすい。

この記事では、ChatGPT、GPTs、Projects、Codexの違いを整理した。次の記事では、もう少し細かく、ChatGPTのPersonality、カスタム指示、メモリ、GPTsの違いを整理する。

関連記事

• ChatGPTに「性格」を持たせるとは何か｜Personality・カスタム指示・メモリ・GPTsの違い
• GPTsを増やしすぎない方がいい理由｜個人運営でAI役割分担が崩れるポイント

参考にした公式情報

• What is ChatGPT: FAQ | OpenAI Help Center
• GPTs in ChatGPT | OpenAI Help Center
• Projects in ChatGPT | OpenAI Help Center
• Introducing Codex | OpenAI

私は普段、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スタンプ販売まで持っていきたい

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

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

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