最近はChatGPTやCodexでコードを書く機会が増えた。

その一方で、

• AIが大量にコードを書き換える
• 動いていたものが急に壊れる
• 修正したら別の場所が壊れる

みたいなことも普通に起きる。

そこで重要になってくるのが Git。

それはわかる。わかるが、いろいろ調べても今一つよくわからない。

ので、自分で記事にすることにした。

この記事では、

• GitとGitHubの違い
• 新規作成からリリースまでの流れ
• branchを使った安全な実験方法
• 壊れた時の戻し方
• 自動デプロイ
• セキュリティ注意点

を初心者向けに整理する。

Gitがあると助かる場面

Gitは単なる「バックアップ」ではない。

実際に助かるのはこういう場面。

・昨日動いていた状態に戻せる
・AI改修前へ戻せる
・別案を安全に試せる
・PC故障時の保険になる
・公開版だけ管理できる
・どの変更で壊れたか追跡できる

AI時代は特に、

「安全に試行錯誤できること」

の価値が大きい。

AIにコードを直してもらう時ほど、先にGitでセーブポイントを作っておくと安心です。

Gitとは

Gitは「変更履歴管理システム」。

簡単に言うと、

ファイルのセーブポイントを残し続ける仕組み

に近い。

Gitがない世界

Gitなしだとありがちなのがこれ。

project_final
project_final2
project_final_last
project_final_last_fix

途中でどれが正しいか分からなくなる。

Gitがあるとどうなるか

flowchart TD

A[ファイルを編集する] --> B[Gitで変更を確認]

B --> C{保存する変更か？}
C -->|はい| D[git add]
D --> E[git commit]
E --> F[履歴として保存]

C -->|いいえ| G[変更を破棄]

F --> H[過去へ戻せる]
F --> I[変更差分を確認できる]
F --> J[どこで壊れたか追跡できる]

Gitは、

• 変更履歴
• バージョン管理
• 復旧

を助ける。

GitとGitHubの違い

ここはかなり混乱しやすい。

Git

履歴管理システム本体。

PCだけでも使える。

flowchart TD

A[ローカルPC]

A --> B[Git]

B --> C[変更履歴]

GitHub

Gitデータをクラウド保管するサービス。

flowchart TD

A[ローカルPC]

A --> B[Git]

B --> C[GitHub]

つまり：

まずはGitだけでも大丈夫。GitHubは、バックアップや共有が必要になってからでも遅くありません。

ローカルGitだけでもかなり価値がある

ここは重要。

初心者は、

GitHub必須

と思いがち。

でも実際には、

• VBA
• WordPress
• Python
• HTML/CSS

くらいなら、

PC内Gitだけでもかなり助かる

まずは：

壊れても戻せる

を体験するだけでも価値がある。

Git操作の流れ

初心者が混乱しやすいのが：

• add
• commit
• push

の違い。

まずはこの流れで考えると分かりやすい。

flowchart LR

A[ファイル編集]

--> B[git add

保存候補へ入れる]
B --> C[git commit
履歴として保存]

C --> D[git push
GitHubへ送る]

新規作成からリリースまでの流れ

初心者向けにかなり簡略化するとこう。

flowchart LR

A[プロジェクト作成] --> B[Git初期化]

B --> C[ファイル編集]

C --> D[commit]

D --> E[GitHubへpush]

E --> F[テスト]

F --> G[リリース]

実際に使うコマンド

Git初期化

git init

現在フォルダをGit管理化する。

状態確認

git status

最重要コマンド。

初心者はまずこれを多用する。

変更追加

git add .

変更ファイルをcommit対象へ入れる。

履歴保存

git commit -m "初回登録"

セーブポイント作成。

GitHubへ送る

git push

GitHubへアップロード。

GitHubから取得

git pull

GitHub側の最新状態を取得。

mainとbranchとは

Gitで重要なのが branch。

main

本線。

現在の安定版。

branch

実験用コピー。

別世界を作るイメージ。

mainをコピーして、

安全な実験空間

を作る。

branchのイメージ

flowchart LR
subgraph MAIN["main（安定版）"]
    M1[v1.0]
    M2[不具合修正]
    M3[v1.1]
end

subgraph BRANCH["feature-ui"]
    B1[UI変更]
    B2[AI改修]
    B3[色調整]
end

M1 -. branch作成 .-> B1
B1 --> B2
B2 --> B3

B3 -. merge .-> M3

なぜbranchが重要なのか

AI時代は特に重要。

例えば：

• Codexで大規模改修
• CSS全変更
• WordPress改造

を直接mainでやると危険。

branchなら：

• 失敗しても捨てられる
• mainは壊れない

ので安全。

branch作成

git branch feature-ui

branch切替

git checkout feature-ui

branch作成＋切替

git checkout -b feature-ui

これをよく使う。

AI改修を頼む前に branch を切る、という癖をつけると事故が減ります。

merge（反映）

問題なければmainへ反映。

git checkout main
git merge feature-ui

Gitを使ったリリースイメージ

Gitは「開発」だけではなく、

公開まで繋がる。

flowchart LR

A[開発]

--> B[テスト]
B --> C[mainへmerge]

C --> D[GitHubへpush]

D --> E[本番公開]

壊れた時の戻し方

Gitの最大価値。

変更取り消し

git restore .

commit前の変更を戻す。

過去commitを見る

git log

履歴一覧を見る。

過去commitへ移動

git checkout コミットID

昔の状態を見る。

reset –hard は強力なので注意

git reset --hard コミットID

完全に戻す。

ただし、

• 作業内容が消える
• 初心者は事故りやすい

ので注意。

reset --hard は強力です。迷ったら、先に別branchを作るか、作業フォルダをコピーしてから実行した方が安全です。

GitHubと自動デプロイ

最近かなり便利。

自動デプロイとは

GitHubへpushすると：

• サーバーへ自動反映
• 公開サイト更新

まで自動化する仕組み。

イメージ

flowchart LR

A[ローカルPC]

--> B[git push]
B --> C[GitHub]

C --> D[GitHub Actions]

D --> E[サーバーへデプロイ]

E --> F[Webサイト更新]

何が便利か

例えば：

• WordPressテーマ
• HTMLサイト
• React
• Pythonアプリ

など。

毎回FTPアップロードしなくてよくなる。

FTPは注意

昔ながらのFTPは危険。

できれば：

• SFTP
• SSH

推奨。

セキュリティ注意点

ここはかなり重要。

APIキーをcommitしない

例えば：

API_KEY=xxxxx
PASSWORD=abc

をGit管理すると危険。

理由

Gitは履歴が残る。

つまり：

一瞬でもcommitすると履歴から掘れる

削除しても危険。

実際に起きている事故

実際には、

• AWSキー流出
• OpenAI APIキー流出
• WordPressパスワード流出

などが起きている。

.gitignore を使う

Git管理除外設定。

.env
node_modules/
vendor/
config.local.php

秘密情報を除外する。

APIキーやパスワードを一度commitすると、削除しても履歴に残ります。公開リポジトリでは特に注意です。

初心者向けおすすめ運用

最初はこれで十分。

Step1

ローカルGit。

PC
 └ Git

まずは「戻せる」ことを覚える。

Step2

GitHub Private。

PC
 ↓
GitHub Private

バックアップ追加。

Step3

自動デプロイ。

GitHub
 ↓
サーバー

更新自動化。

AI時代はGitが重要

最近は特に重要。

AIは：

• 一括変更
• 大量修正
• 想定外変更

を普通にやる。

つまり、

「戻せる前提」

がかなり重要になる。

Gitはその保険。

よく使うGitコマンド一覧

まとめ

Gitは、

「完成品保存」

ではなく、

「安全に試行錯誤するための履歴管理」

に近い。

特にAI開発では：

• 壊れる速度が速い
• 修正範囲が広い
• 何を変えたか追いにくい

ので、Gitの価値がかなり上がっている。

個人開発でも、

• 復旧性
• 実験性
• 継続改善

を考えるなら、かなり重要な基盤だと思う。

JADERは、PMDAが公開している医薬品副作用データベースだ。副作用が疑われる症例報告をもとにしたデータであり、医薬品と有害事象の関係を考えるうえで参考になる。

ただし、報告件数が多いから危険、少ないから安全、という読み方はできない。使用患者数、報告されやすさ、重複、併用薬、症例背景など、さまざまな要素が影響するためだ。

今回の作業は、JADERを研究として深掘りするというより、発表資料で使えるように必要な観点でデータを整理し、集計表やグラフの形に落とし込むことが主な目的だった。

今回の作業範囲

作業の内容は、JADERデータの内容確認、分析対象となる薬剤・有害事象の絞り込み、SPSSで扱いやすい形へのデータ整理、件数集計・クロス集計・割合の算出、発表資料用の表・グラフの作成、結果の読み取りメモの作成だ。

分析ツールはSPSSを使用した。Excelでもある程度の集計はできるが、項目数が多く条件を切り替えながら集計する場合は、SPSSの方が作業の見通しを立てやすい。特に、クロス集計やカテゴリ別集計を繰り返す場面では、どの条件で集計したのかを残しやすい点が助かった。

JADERデータで最初に注意したこと

最初に気を付けたのは、JADERのデータを「そのまま比較に使えるデータ」と見なさないことだった。

JADERは副作用が疑われる症例報告を集めたデータであり、医薬品を使ったすべての患者を把握しているわけではない。報告件数が多くなる理由には、使用患者数が多い、注目されている薬剤で報告されやすい、同じ症例に複数の有害事象が登録されている、といったことが挙げられる。

このあたりを整理しないままグラフにすると、発表資料としては見やすくても、読み手に誤解を与える可能性がある。今回の取りまとめでは、「件数が多い＝危険」と読める表現は避けた。

SPSSに取り込む前の整理

JADERのデータは、そのままSPSSに入れれば終わり、というものではなかった。分析対象にする項目を確認し、どの単位で集計するかを先に整理する必要があった。

特に迷ったのは、症例単位で見るのか、薬剤単位で見るのか、有害事象単位で見るのかという点だ。同じ症例に複数の薬剤や有害事象が紐づく場合があるため、集計単位を曖昧にしたまま作業すると件数の意味が分からなくなる。

作業前に、1行が何を表しているのか、症例番号をキーとして扱えるか、集計結果の件数は症例数なのか報告数なのか、発表資料ではどの粒度で見せるべきかを確認した。ここを先に決めておかないと、後から表やグラフを作ったときに説明が難しくなる。

SPSSで行った主な集計

主な集計は、対象薬剤ごとの報告件数、対象有害事象ごとの報告件数、年齢区分・性別・転帰別の集計、薬剤と有害事象のクロス集計、条件を絞ったサブグループ集計だ。

発表資料用の分析だったため、集計できる項目をすべて出すのではなく、説明に使えるものを選ぶ必要があった。全部出すと資料として逆に分かりにくくなる。そのため、まず全体像を見せ、次に対象薬剤・有害事象に絞り、必要に応じて背景情報を加え、最後に読み取り上の注意点を添える順番で整理した。

発表資料用に意識した見せ方

SPSSの出力表は確認用としては便利だが、そのままスライドに載せると情報量が多すぎる。発表資料では、表は必要な列だけに絞り、件数と割合の意味を明確にし、グラフは比較したい項目だけに限定した。

特に意識したのは、断定的な因果関係に見える表現を避けることと、注釈でJADERデータの性質を補足することだ。棒グラフにすると差が強調されるが、その差が本当に意味のある差なのかは別の問題である。グラフ化する場合でも、単純な順位付けに見えすぎないよう注意した。

苦労した点と得たこと

IT関連の業務に関する分析・統計は知見があったが、医療統計、SPSSの使い方も学習しながらの業務となった。分析をするまでについても簡単ではなかった。

さらに苦労したのは、分析そのものよりも結果の意味をどう説明するかだった。JADERのようなデータでは件数は出せる。しかしその件数をどう読むかは簡単ではない。

発表資料では限られたスライド数の中で説明する必要があり、注意点を省きすぎると単純な安全性比較のように見えてしまう。そのため、主な結果は絞り、補足資料として集計表を残し、スライド上には注釈を入れ、「傾向を確認するための集計」として位置づけるバランスを取った。

今回の作業で感じたのは、集計作業そのものよりも前提条件の整理が重要だということだ。どの単位で数えているのか、何を比較しているのか、その結果から何を言ってよいのかを整理しないと、発表資料としては危ういものになる。ツールよりも、最初の設計の方が重要だった。

まとめ

JADERデータの分析取りまとめでは、SPSSを使って発表資料用の集計表やグラフを作成した。重要だったのはSPSSの操作そのものではなく、JADERデータの性質を踏まえて結果をどう見せるかだった。

JADERは医薬品と有害事象の関係を考えるうえで有用なデータだが、単純な件数比較で安全性を判断できるものではない。その前提を崩さずに発表資料として整理する。今回の作業は、公開データを使った分析結果を誤解されにくい資料に整えるための実務だった。

要件は「休暇申請は管理者が承認する」「休暇はカレンダーで全員で参照可能とする」である。

休暇申請は「申請フォームを作る」だけでは終わらない。申請者が入力し、承認者に通知が届き、承認・却下され、カレンダーに反映され、結果が通知される。この一連の流れがつながっていないと、結局どこかで手作業が残る。

今回は、Microsoft 365環境の中で使える仕組みを前提に、休暇申請から承認、カレンダー登録、通知までをできるだけ一つの流れにまとめた。

作成したワークフローの概要

今回作成した休暇申請フローは、次のような流れで動作する。

1. 申請者が登録済みの休暇予定を確認する
2. Microsoft Formsから休暇申請を送信する
3. 承認者へTeamsまたはOutlookで承認依頼を通知する
4. 承認者が申請内容を承認または却下する
5. 承認された休暇を指定のカレンダーへ登録する
6. 申請者へ結果を通知する

申請フォームはMicrosoft Formsで作成し、処理のつなぎ込みはPower Automateで行う構成とした。通知先はTeamsとOutlookのどちらにも対応できるよう整理した。

対応した休暇パターン

複数日にまたがる休暇

申請フォームで開始日と終了日を受け取り、承認後にカレンダーへ一括登録できるようにした。1日ずつ手作業で登録する手間がなくなるだけでなく、共有カレンダー上で見える形にすることで、チームメンバーが後から確認しやすくなる。

時間休

申請フォーム内に時間を記入する欄を設け、カレンダー登録時の予定名や補足情報に反映する想定とした。午前休・午後休・指定時間帯など、運用によって必要な表現は変わるため、要件定義の段階で入力項目と表示内容を調整する前提にした。

承認者への通知

Formsから申請が送信されると、Power Automateが起動し、承認者へ承認依頼を送信する。承認者は、申請者名・休暇日・休暇区分・理由などを確認し、その場で承認または却下できる。

意識したのは、承認者が別の画面を探しに行かなくても判断できることだ。通知が届いても内容が足りなければ、結局Formsの回答や別ファイルを確認する必要が出てくる。そのため、承認画面上に必要な情報をできるだけ集約する構成にした。

承認後のカレンダー登録

承認された申請については、指定されたカレンダーへ休暇予定を登録する。登録先は、部署内の休暇共有カレンダーやチームのOutlook予定表など、運用側で用意してもらう前提とした。

休暇情報は、チームとして確認できる場所に反映されて初めて業務調整に使える情報になる。特に、複数人の休暇予定を確認しながら調整する職場では、カレンダー連携の効果は大きい。

申請者への通知

承認結果は申請者にも通知する。承認時はチームへの共有も兼ねて、チームメンバーへも通知する形を想定した。一方、却下時はチーム全体に共有する必要は薄いため、申請者（または代行申請の場合は代行者）への個別通知とした。承認時と却下時で通知先を分けることで、必要以上に情報を広げない運用にできる。

作ってみて重要だと感じた点

申請フォームだけでは業務改善にならない

Formsで入力を受け付けるだけでは、自動化としては半分しか完結していない。承認者への通知、承認結果の保存、カレンダー登録、申請者への返答、チームへの共有——このあたりまで含めて考えないと、フォームだけ増えて裏側の手作業が残る。

カレンダー登録までつなげると効果が出やすい

休暇申請は、承認されて終わりではない。承認済みの休暇を共有カレンダーへ反映しておけば、後からメールや申請履歴を探す手間が減る。

通知先はTeamsとOutlookのどちらがよいか

どちらが優れているかではなく、現場で普段どちらを見ているかで決める方がよい。Teamsを日常的に使っている組織ではTeams通知の方が見落としにくく、正式な通知や記録性を重視する場合はOutlookメールが扱いやすいこともある。

個別の会社ルールに合わせる必要がある部分

休暇申請は会社ごとのルール差が出やすい。休暇区分の種類、承認者の決め方、却下時の通知先、カレンダーに表示する文言、休暇理由をどこまで共有するかといった点は、事前に確認が必要になる。

特に注意が必要なのは、休暇理由の扱いだ。承認者には見せるとしても、チーム全体に同じ情報を通知してよいとは限らない。承認者向けの情報とチーム共有向けの情報は分けて考える必要がある。

まとめ

休暇申請ワークフローは、申請フォームを作るだけでは完結しない。承認者への通知、承認・却下、カレンダー登録、申請者への結果通知までつながって初めて、現場の手間が減る。

今回の構成では、Microsoft Forms・Power Automate・Teams・Outlook予定表を組み合わせることで、一連の流れを自動化した。大きな業務システムを新しく作らなくても、既存のMicrosoft 365環境を活用しながら比較的小さく始められるのが、この構成の扱いやすさだと感じた。

この記事では、Excel XLOOKUP関数を実務の作業メモとして整理する。関数の説明だけで終わらせず、どこで使い、どこで崩れやすく、他の方法とどう使い分けるかまで見ていく。

Excel XLOOKUP関数とは

XLOOKUP関数は、指定した値を検索して対応する値を返す関数だ。VLOOKUPの後継にあたる位置づけで、検索範囲と戻り範囲を別々に指定できる点が大きな違いである。VLOOKUPで必要だった「何列目を返すか」という列番号の指定が不要になり、列の追加・削除による式崩れが起きにくい。

ただし、使えるのはMicrosoft 365またはExcel 2021以降だ。共有先のExcel環境で開くファイルに使う場合は、相手側のバージョンを先に確認しておくのが無難である。

XLOOKUPは便利だが、相手先のExcelで開けるかは別問題。共有先の環境は先に見る。

基本構文

excel

=XLOOKUP(lookup_value,lookup_array,return_array,[if_not_found],[match_mode],[search_mode])

• lookup_value（必須）：検索したい値
• lookup_array（必須）：検索する範囲（1列または1行）
• return_array（必須）：返す値がある範囲
• if_not_found（省略可）：一致しなかったときに返す値。省略すると #N/A が表示される
• match_mode（省略可）：一致の種類。0が完全一致（省略時のデフォルト）
• search_mode（省略可）：検索の方向。1が先頭から（省略時のデフォルト）

関数名が認識されない場合は、式を直す前にExcelのバージョンや更新チャネルを確認したい。

基本例

excel

=XLOOKUP(E2,A2:A100,C2:C100,"該当なし")

E2の値をA列で検索し、一致した行のC列の値を返す。一致しない場合は「該当なし」を表示する。最初は小さい範囲で動作を確認してから実表に広げるとよい。いきなり全体に入れると、エラーが出たときに原因の切り分けが難しくなる。

実務でよく使うパターン

社員IDから氏名や部署を返す

社員IDが入力されたセル（E2）を起点に、社員マスタのID列を検索して氏名や部署を返す使い方だ。

excel

=XLOOKUP(E2,社員マスタ[社員ID],社員マスタ[氏名],"該当なし")

テーブル参照にしておくと、社員の追加・削除が起きても範囲が自動で広がるため式が崩れにくい。return_arrayを 社員マスタ[部署] に変えるだけで返す列を切り替えられるのも、VLOOKUPと比べて変更しやすい点だ。

商品コードから単価を返す

注文書や見積書など、商品コードを入力したら単価が自動で入る仕組みを作るときの基本形だ。

excel

=XLOOKUP(E2,商品マスタ[商品コード],商品マスタ[単価],"該当なし")

商品コードの書式（文字列か数値か）が検索側と一致していないと、正しく検索できないことがある。エラーが出た場合はまず元データの型を確認する。

検索列の左側にある値を返す

VLOOKUPは検索列より右の列しか返せないが、XLOOKUPは検索範囲と戻り範囲を独立して指定するため、左側の列も返せる。

excel

=XLOOKUP(E2,C2:C100,A2:A100,"該当なし")

C列で検索してA列（左側）の値を返す例だ。表の構造を変えずに左方向の検索ができるのは、XLOOKUPの実務上の利点のひとつである。

よくあるエラー・うまくいかない原因

• 関数名が認識されない：ExcelのバージョンがMicrosoft 365またはExcel 2021以降かを確認する
• lookup_arrayとreturn_arrayのサイズが合っていない：行数または列数が異なると結果が崩れる。それぞれの範囲が同じサイズになっているかを見る
• 完全一致しない：match_modeを省略すると完全一致（0）になる。近似一致やバイナリ検索を使う場合は、データが昇順・降順に並んでいる前提があることを確認する

エラーが出たときは、関数の引数だけでなく元データの状態を見るのが先決だ。空白に見えるセルにスペースが入っている、日付に見える値が文字列になっている、といった原因は実務でよく起きる。

式を長くする前に、元データの型、空白、範囲サイズを確認する。ここを飛ばすと、正しい式でも期待通りに動かない。

似た関数・古いやり方との使い分け

XLOOKUPはVLOOKUPと比べて、列番号の指定が不要・左方向の検索が可能・一致しない場合の表示を引数で設定できるという点で扱いやすい。

一方、VLOOKUPはExcel 2010以降であれば使えるため、古い環境と共有するファイルでは今も現役だ。既存ファイルに組み込まれたVLOOKUPを無理に書き換える必要はない。新規で作るファイルでバージョンの問題がなければXLOOKUPを選ぶ、という使い分けで十分である。

他の関数との組み合わせ

• FILTER関数：複数条件で絞り込んだ結果をXLOOKUPに渡すより、複数行を返したい場合はFILTERの方が向いている場面もある。役割の違いを意識して使い分けるとよい
• SUMIFS関数：「一致した値を合計したい」場合はXLOOKUPではなくSUMIFSを使う。XLOOKUPは単一の値を返す関数であり、集計には向いていない
• LET関数：同じ範囲を複数回参照する式が長くなった場合、LETで中間結果に名前を付けると読みやすくなる

複数の関数を組み合わせるときは、まず「何をしたいか」を役割ごとに分けて考えるとよい。検索・抽出・集計・並べ替えをひとつの式に詰め込むと後から読みにくくなる。

まとめ

Excel XLOOKUP関数は、VLOOKUPの使いにくさを解消した検索関数だ。列番号の指定が不要で、左方向の検索にも対応している。一方で、使える環境がExcel 2021またはMicrosoft 365以降に限られるため、共有先のバージョン確認は先に済ませておきたい。

範囲・データ型・空白・バージョンまで含めて把握しておくと、式の失敗原因を切り分けやすくなる。

この記事では、重複なしリストを自動作成する実務手順を整理する。

UNIQUE関数で重複なし一覧を作る

excel

=UNIQUE(A2:A100)

この式は、A2:A100の範囲から重複しない値を一覧として返す。結果は複数セルに広がる（スピル）ため、出力先のセルを空けておく必要がある。既存の値があると #SPILL! エラーになる。

重複の削除機能との違い

Excelの「重複の削除」は、選択したデータ自体を直接書き換える操作だ。一度だけ固定リストを作るなら手軽で使いやすい。

UNIQUE関数は、元データを残したまま別の場所に重複なし一覧を作る。元データが更新されると結果も自動で変わるため、継続的に使うリストにはUNIQUEの方が運用に合いやすい。

リストを手で更新し始めたら、だいたい抜け漏れが出る。更新される元データなら数式化しておく価値がある。

元データが増える場合はテーブル化する

固定範囲のままだと、101行目以降に追加したデータが式の対象に入らない。元データをExcelテーブルに変換しておくと、行追加時に参照範囲が自動で広がるため崩れにくくなる。

excel

=UNIQUE(売上一覧[担当者])

テーブル化の手順は、元データを選択して「挿入」→「テーブル」から行える。テーブル名は後から「テーブルデザイン」タブで変更できる。

SORTと組み合わせて並べ替える

UNIQUE単体では、結果の並び順が元データの出現順になる。見やすくしたい場合や、プルダウンリストとして使う場合はSORTを組み合わせるとよい。

excel

=SORT(UNIQUE(売上一覧[担当者]))

FILTERと組み合わせて条件付きリストにする

地域や部署で絞った上で重複なし一覧を作るなら、FILTERを内側に組み合わせる。

excel

=UNIQUE(FILTER(売上一覧[担当者],売上一覧[地域]=B1))

B1に地域名を入れると、その地域の担当者だけを重複なしで一覧表示できる。B1の値を変えると結果も自動で切り替わる。

プルダウンリストの元データにも使える

UNIQUEで作った一覧は、入力規則（データの入力規則）のリストの元データ候補として使える場合がある。ただし、スピル範囲をそのまま参照するには # 演算子を使う方法があり、Excelのバージョンによって挙動が異なる。公開前に実ファイルで動作を確認しておきたい。

まとめ

重複なしリストを継続して使うなら、UNIQUE関数・テーブル化・SORTの組み合わせが扱いやすい。条件で絞り込んだ上で一覧を作りたい場合はFILTERを足す。元データを直接加工せず、数式として管理しておくことで、更新のたびに手直しする手間を減らせる。

役割が違うぶん、組み合わせ方にも順番がある。この記事では、3つを単独で使う場合、2つずつ組み合わせる場合、3つすべてを組み合わせる場合に分けて整理する。

使い分け表

FILTERは条件抽出

excel

=FILTER(A2:F100,C2:C100="東日本","該当なし")

FILTERは、指定した条件に合う行だけを取り出す関数だ。第3引数に「該当なし」のような文字列を入れておくと、条件に一致するデータがなかったときのエラー表示を防げる。別シートに条件付き一覧を作るときの主役になる関数である。

SORTは並べ替え

excel

=SORT(A2:F100,1,1)

SORTは、一覧の並び順を整える関数だ。第2引数で基準にする列番号、第3引数で昇順（1）・降順（-1）を指定する。抽出した結果をそのまま並べ替えたいときは、FILTERの外側にSORTを重ねて使うことが多い。

UNIQUEは重複なし一覧

excel

=UNIQUE(A2:A100)

UNIQUEは、元データに手を加えず、重複を除いた一覧を別のセルに返す関数だ。集計表の行見出しや、プルダウンリストの元データを作るときに使いやすい。元データが更新されると結果も自動で変わるため、繰り返し使う一覧管理に向いている。

この3つは順番の関数。何を先に絞って、何を残して、最後にどう見せるかを考える。

2つずつ組み合わせる例

FILTER + SORT

excel

=SORT(FILTER(A2:F100,C2:C100="東日本"),1,1)

条件に合う行を取り出してから並べ替える。FILTERで絞った結果がそのまま並べ替えの対象になるため、SORTを外側に置く形になる。

UNIQUE + SORT

excel

=SORT(UNIQUE(A2:A100))

重複なし一覧を作ってから、見やすい順に並べる。プルダウンリストの元データとして使う場合は、この形にしておくとユーザーが探しやすい。

FILTER + UNIQUE

excel

=UNIQUE(FILTER(A2:A100,B2:B100="東日本"))

条件に合うデータだけを対象にして、重複なし一覧を作る。UNIQUE単体では全データが対象になるが、FILTERを内側に入れることで絞り込んだ範囲の重複除外ができる。

3つ全部を組み合わせる例

excel

=SORT(UNIQUE(FILTER(A2:A100,B2:B100="東日本")))

この式は、東日本のデータだけを抽出し、重複を除き、最後に並べ替える。内側から「何をするか」が決まる構造なので、まずFILTERで絞り込み、次にUNIQUEで重複を除き、最後にSORTで見せ方を整える、という順番で組み立てると考えやすい。順番を変えると意味が変わるため注意が必要だ。

数式が長くなったらLETを検討する

excel

=LET(data,FILTER(A2:A100,B2:B100="東日本"),SORT(UNIQUE(data)))

入れ子が深くなると、後から修正したいときに読み解くのに時間がかかる。LETを使って中間結果に名前を付けておくと、式が何をしているかの意図が残りやすく、メンテナンスしやすくなる。

まとめ

FILTER、SORT、UNIQUEは、抽出・並べ替え・重複なしという別の役割を持つ関数だ。組み合わせるときは、最終的に得たい結果から逆算して、内側から順番に組み立てていくと整理しやすい。

この記事では、Excel UNIQUE関数を実務の作業メモとして整理する。関数の説明だけで終わらせず、どこで使い、どこで崩れやすく、他の方法とどう使い分けるかまで見ていく。

Excel UNIQUE関数とは

UNIQUE関数は、指定した範囲から重複を除いた値の一覧を返す関数だ。元データを直接書き換えるのではなく、別の場所に「重複なしの結果」を動的に表示できるのが特徴である。

元データが更新されると結果も自動で変わるため、継続的に使う一覧管理に向いている。一方で、Excelのバージョンによっては使えない場合があるため、共有先の環境には注意が必要だ。

重複を消すというより、元データの横に「重複なしビュー」を作る感覚で使うと管理しやすい。

基本構文

excel

=UNIQUE(array,[by_col],[exactly_once])

• array（必須）：重複を除きたい範囲
• by_col（省略可）：TRUEで列方向に比較。省略するとFALSE（行方向）
• exactly_once（省略可）：TRUEにすると、1回だけ登場する値のみを返す

この関数が使えるのはMicrosoft 365またはExcel 2021以降だ。関数名が認識されない場合は、式を直す前にExcelのバージョンや更新チャネルを確認したい。

基本例

excel

=UNIQUE(A2:A100)

最初は小さい範囲で試すのが基本だ。いきなり実表全体に入れると、エラーが出たときに原因が範囲なのか、条件なのか、データの型なのか切り分けにくくなる。1列・短い範囲で結果を確認してから広げていくとよい。

実務でよく使うパターン

1列の担当者名から重複しない担当者一覧を作る

excel

=UNIQUE(A2:A100)

担当者名が入ったA列に対してそのまま使える。注意したいのは範囲の固定だ。行が追加されるたびに式が古くならないよう、継続運用する表ではExcelテーブルに変換して列名で参照する方法が崩れにくい。

excel

=UNIQUE(テーブル1[担当者])

テーブル参照にしておくと、行追加時に自動で範囲が広がるため、式を直す手間がなくなる。

部署と担当者の2列を組み合わせて、ペア単位で重複を除く

複数列をまとめて対象にしたい場合は、範囲を列ごとに広げるだけでよい。

excel

=UNIQUE(A2:B100)

この場合、「部署と担当者の組み合わせ」が一致するものを重複と見なして除外する。どちらか片方だけ同じでも、組み合わせが違えば別の行として残る。

SORT関数と組み合わせて並べ替えた状態で表示する

excel

=SORT(UNIQUE(A2:A100))

UNIQUE単体では元データの出現順に結果が並ぶ。SORT関数を外側に組み合わせると、重複を除きつつ昇順に並べ替えた一覧を返せる。ドロップダウンリストの元データとして使う場合などは、この形にしておくと見やすい。

よくあるエラー・うまくいかない原因

• スピルエラー（#SPILL!）：結果が複数セルに広がる（スピル）ため、出力先のセルに既存の値があると動作しない。出力先を空にしてから入力する
• 空白が残る：元データに空白セルが含まれると、空白も一意の値として結果に含まれることがある。FILTER関数と組み合わせて空白行を除外するとよい
• 範囲が古くなる：元データが増える運用では、固定範囲（A2:A100など）より前述のテーブル参照の方が崩れにくい

エラーが出たときは、関数の引数だけでなく元データの状態を確認するのが先決だ。空白に見えるセルにスペースが入っている、日付に見える値が文字列になっている、といった原因は実務でよく起きる。

式を長くする前に、元データの型、空白、範囲サイズを確認する。ここを飛ばすと、正しい式でも期待通りに動かない。

似た機能・古いやり方との使い分け

「重複の削除」機能との違いは明確だ。重複の削除はその時点のデータを直接書き換える操作で、元に戻すには元データを保持しておく必要がある。UNIQUE関数は元データを残したまま、別セルに動的な結果一覧を作る。提出用データを一度だけ整理するなら「重複の削除」でも問題ないが、元データが更新される一覧を管理するならUNIQUEが向いている。

古いやり方を全部捨てる必要はない。既存ファイルの環境、共有先のExcelバージョン、作業が一度きりか繰り返しかで、使うべき方法は変わる。

他の関数との組み合わせ

• FILTER関数：条件に合う行だけを先に絞り込んでからUNIQUEに渡すことで、「特定の部署の担当者一覧」のような絞り込み＋重複除外ができる
• SORT関数：UNIQUE関数の結果をそのまま並べ替える。=SORT(UNIQUE(A2:A100)) のように外側に重ねて使う
• TEXTSPLIT関数：1セルに「,」区切りで入った値を分割してからUNIQUEに渡すと、結合された文字列でも重複除外が可能になる

複数の関数を組み合わせるときは、最初に「何をしたいか」を役割ごとに分けて考えるとよい。抽出・並べ替え・重複除外・文字列変換を一つの式に詰め込むと後から読みにくくなる。式が長くなる場合はLET関数で中間結果に名前を付ける選択肢もある。

まとめ

Excel UNIQUE関数は、構文を覚えるだけでは実務に乗りにくい。範囲・データ型・空白・出力先・共有先のExcel環境まで含めて把握しておくと、式の失敗原因を切り分けやすくなる。

継続的に更新されるデータで「重複なし一覧」を管理する場面では、「重複の削除」機能よりUNIQUE関数の方が運用しやすい。FILTER・SORTと組み合わせることで、より実用的な使い方に広げられる。

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

ブログ用のチャット。
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

当時、私は不動産業務についてほとんど知識がありませんでしたが、実際にお客様とWeb会議を

重ねる中で、これまでの知見も生かし、「必要とされる機能を利用しやすい形で」を目指して

お客様と共にシステム化を進めました。

結果として、この案件は1次開発から4次開発まで続き、段階的に改善を重ねる形になりました。

今回は、その流れを振り返ってみます。

なぜExcelから始めたのか

最初に検討したのは、「どこまでシステム化するべきか」でした。

一般的には、最初からWebシステムやクラウドサービスを想像しがちです。

ただ、実際には、

• 利用人数がそこまで多くない
• Excel運用に慣れている
• ITリテラシーに差がある
• まず業務整理が必要

という状況でした。

そのため、最初から大きなシステムを作るのではなく、

「今の業務を壊さずに改善する」

ことを優先し、Excelベースで進めることにしました。

1次開発：まずは業務を理解する

最初の開発では、

• 不動産業者をマスタ管理
• 業者ごとに案内した物件情報を管理
• PDF資料を添付保存

といった基本機能を実装しました。

この時点では、不動産業界特有の業務知識がほとんどありませんでした。

そのため、実装よりも先に、

• どんな流れで業務が進むのか
• 誰が何を見ているのか
• どこで困っているのか

をWeb会議で丁寧に確認することを重視しました。

実際、小規模業務改善では「技術」より「業務理解」の方が重要だと感じています。

2次開発：部署ごとの運用と集計機能

1次開発したツールは、部署ごとに配布して利用する形になりました。

ただ、運用が始まると、

「部署ごとのデータをまとめたい」

という要望が出てきました。

そこで2次開発では、

• 部署ごとのデータをマージする機能
• 成績グラフの自動生成
• VPSサーバーによる共有環境

を追加しました。

特に印象的だったのは、「分析したい」というニーズが徐々に強くなっていったことです。

単に記録するだけでなく、

• どの部署が成果を出しているか
• どの業者との取引が多いか

を見たいという要望が増えていきました。

現場で実際に使われ始めると、必要な機能が具体化していくのを感じました。

3次開発：Accessへの移行

運用が進むにつれて、管理する業者数も増えていきました。

その結果、Excelだけでは扱いづらくなってきたため、データ管理部分をAccessへ移行しました。

ただし、入力画面はExcelを維持しました。

これは、

「利用者の使用感を変えない」

ためです。

もし入力方法まで大きく変えてしまうと、現場負荷が増えてしまいます。

小規模業務改善では、

「技術的に正しいか」

だけでなく、

「現場で使い続けられるか」

が非常に重要だと感じています。

また、2次開発で追加したグラフ機能も強化し、さまざまな軸で実績を確認できるよう改善しました。

ちなみにですが、Accessのライセンスは不要になる点も、この形態とした理由の一つです。

4次開発：OCRへの挑戦

4次開発では、新たにPDFで送られてくる物件情報の電子化に挑戦しました。

Pythonを利用し、OCR処理によって情報を読み取る仕組みを作成しました。

ただ、実際に試してみると、100%正確に読み取ることはできませんでした。

帳票形式の違いや文字品質の問題もあり、完全自動化には限界がありました。

そこで最終的には、

• OCR結果を保存
• 元画像も保存
• 目視確認しやすいUIを用意
• 修正しやすい形にする

という方向へ切り替えました。

「完全自動化」ではなく、

「確認作業を減らす」

方向へ落とし込んだ形です。

今振り返っても、この判断は間違っていなかったと思っています。

小規模業務改善で大事だと感じたこと

この案件を通して感じたのは、

「最初から完璧を目指さない」

ことの重要性でした。

特に小規模事業では、

• 現場に合うか
• 続けられるか
• 壊れないか
• 修正しやすいか

の方が重要になる場面が多いです。

最初から大規模システムを作るのではなく、

• Excelから始める
• 必要に応じて拡張する
• 運用しながら改善する

という進め方は、今でも有効だと感じています。

おわりに

最近はAIや自動化の話題も増えていますが、

実際の現場では、

「どこまで自動化するか」

より、

「どうすれば現場で使い続けられるか」

の方が重要になることも多いです。

この案件は、自分にとっても「業務改善とは何か」を考えるきっかけになった案件でした。

今後も、現場運用を壊さない形の改善を意識していきたいと思っています。