PR：この記事は、CodexでAI業務ツールを作った実体験をもとに書いています。広告・アフィリエイトリンクを含む場合があります。
CodexでAI業務ツールを作っていたら、気づけば自分がAIの作業員になっていました。
これは、非エンジニアがCodexでAI業務ツールや小さなアプリ制作キットを作ろうとして、ZIP、HTML、JavaScript、manifest、README、検収ファイルの海で普通に迷子になった記録です。
もともとの入口はAI事務所キットでしたが、この記事の主役はそこからCodexへ踏み込んだ瞬間に起きた「作業員化」です。
先に結論を書くと、Codexはすごいです。
ただし、目的、完成条件、正本ファイル、検収手順を人間側が握っていないと、AIに作らせているつもりで、自分がAIの指示どおりに動く作業員になります。
AIを使う側に残るには、プロンプトだけでは足りません。必要なのは、AI制作ディレクションでした。
この記事で書くこと
- AI事務所キット制作では、まだ自分が設計者だったこと
- Codexに入った瞬間、ファイルとZIPで現在地を見失ったこと
- AIを手足にするはずが、自分がAIの手足になっていたこと
- 非エンジニアがCodexを使うなら、プロンプトだけではなく、目的・完成条件・検収の地図が必要だと分かったこと
Codexに入る前は、まだ自分が設計者だった
最初に作っていたのは、AI事務所そのものではありません。
Claude CoworkやChatGPTチェーンプロンプトを使って、非エンジニアでも自分用のAI事務所を作れるようにするための、構築キットを作っていました。
入口役のAIがいて、調査担当がいて、文章作成担当がいる。
点検担当のAI、引き継ぎ用のHandoff、道具箱としてのSkill、最後に全体を確認するCoreまで置く。
こういう部品を、購入者が自分の業務に合わせて組み立てられるようにする。
Codex以前に作っていたのは、完成品ではなく「構築キット」だった
要するに、私が作っていたのは、AI事務所の完成品ではなく、AI事務所を作るための設計図と部品セットでした。
ここまでは、かなり「作っている感覚」がありました。
自分が何を設計しているのか分かっていたし、どのAIに何を任せるのかも分かっていた。購入者がどこで迷うかも、ある程度想像できていました。
なかなか立派です。
脳内では完全に、AI事務所構築士です。
国家資格ではありません。たぶん今後もできません。
ClaudeやChatGPTでは、作っている感覚があった
Claude CoworkやChatGPTチェーンプロンプトでAI事務所キットを作っていたときは、ちゃんと自分が設計している感覚がありました。
入口をどこに置き、誰に何を頼み、調査をどのAIスタッフに任せ、最後に誰が確認するのか、成果物をどう引き継ぐのか。
その流れが、自分の頭の中にありました。
だから作業は大変でも、少なくともこう思えていました。
ああ、俺はいまAI事務所キットを設計しているんだな。
入口、役割、引き継ぎ、確認が見えていた
これは大事です。
人間は、意味が分かっている作業なら耐えられます。たとえ手数が多くても、ゴールが見えていれば、まだ仕事として受け止められます。
作っていたのは、購入者が自分でAI事務所を組み立てるためのキットです。
完成したオフィスを渡すのではなく、オフィスを作るための設計図、初期設定、役割分担、引き継ぎ方法、確認手順を渡す。いわば、AI時代の小さな事務所づくりの道具箱です。
かなりざっくり言えば、会社の中で仕事をつないでいくような感覚でした。まず相談を受ける入口があり、必要な調査へ回し、文章作成や業務整理へつなぎ、最後にCoreで確認する。
AIスタッフそのものを作っていたというより、AIスタッフを配置できる設計キットを作っていたのです。
だから「この人にはこの役割」「この作業はこの流れ」「最後にここで確認」という絵が見えていました。
少なくとも、この時点では、私はAIを手足にしていました。
まだ、かろうじて主役は人間でした。
Codexに入った瞬間、現在地を見失った
ところが、CodexでAI業務ツールや小さなアプリを作ろうとした瞬間、話が変わりました。
急に、AGENTS.md、SPEC.md、TASK_01.md、VALIDATION.md、README.md、app/index.html、app/app.js、manifest.json、ZIP、修正版ZIP、検収済みZIP、販売用パック候補ZIPが視界に入ってきます。
もはや、何かの捜査資料です。
ZIP、HTML、JS、manifest、検収で普通に迷子になる
ChatGPTに言われるがまま、フォルダを開き、ファイルを見て、ZIPを展開する。
デモを確認して、文字化けを見つけ、また直す。
直したと思ったら、またZIPを見る。
そして、どれが正本か分からなくなる。
このあたりで、私はうっすら思いました。
俺はいま、何をしているんだ？
ClaudeやChatGPTのときは、「AI事務所キットを設計している」という意識がありました。
でもCodexでは、いつの間にか「何かのファイルを確認している人」になっていました。
設計者のはずが、急に現場作業員です。
しかも、現場の看板には英語でmanifest.jsonと書いてあります。
読めるけど、心は読めません。
Codexはすごいです。
コードも直せるし、ファイルも見られる。
構成も整えられるし、デモも作れる。
文字化けまで直せる。
ただし、非エンジニア側が全体像を握っていないと、すぐに迷子になります。
いま何を作っているのか、どのファイルが何の役割なのか、どれが最新版なのか、何を確認すれば完成なのか。
このあたりが曖昧なまま進むと、AIが優秀であるほど、人間側が置いていかれます。
CodexでAIを手足にするはずが、俺がAIの手足になっていた
ここで気づきました。
私は、AIを手足にしてAI事務所キットを作るはずでした。でも実際には、AIに言われた通りにフォルダを開き、AIに言われた通りにファイルを確認し、AIに言われた通りにZIPを展開し、AIに言われた通りにまた確認していました。
つまり、こうです。
AIを手足にするはずが、俺がAIの手足になっていた。
これは仕事ではなく、作業だった
仕事には、自分の判断があります。何を作るのか、誰に届けるのか、どこまでできたら完成なのか。これは売れるのか、購入者に分かるのか、商品として成立しているのか。そういう判断をしているとき、人は仕事をしています。
でも、意味が分からないまま「次はこれを開いてください」「次はこれを確認してください」「次はこのZIPを見てください」と進んでいくと、だんだん自分が消えていきます。
昔なら、封筒にチラシを入れる内職だったかもしれません。
令和では、ZIPを展開してapp.jsを眺めています。
時代は進みました。
虚無は、ちゃんと最新版にアップデートされています。
もちろん、Codexが悪いわけではありません。むしろCodexはすごいです。ただ、使い方を間違えると、AIに仕事をさせているつもりで、自分がAIの作業員になります。
ここが、今回の一番大きな発見でした。
Codex制作はプロンプトエンジニアリングとは別物だった
私は、Codexで商品やツールを作ることも、プロンプトエンジニアリングの延長線にあると思っていました。
指示を整え、役割を与え、出力条件を決め、チェック項目を用意する。いつものようにそこを固めれば、AIがいい感じに形にしてくれる。
そう思っていた時期が、私にもありました。
Codexで必要なのは、AI制作ディレクションだった
でもCodexで商品やツールを作るとなると、話が変わります。仕様書、ファイル構成、HTML、JavaScript、manifest、動作確認、文字化け、ZIP、正本管理、検収。プロンプトを書いて終わりではなく、できたものを見て、触って、壊れていないか確認する必要があります。
つまり、これはプロンプトエンジニアリングというより、AI制作ディレクションでした。
そして私はその初日、見事に作業員になりました。配属初日から、現場です。しかも研修資料は、だいたい英語のファイル名です。
AIを使ってツールやキットを作るなら、必要なのはプロンプトだけではありません。何を作るのか、誰に使ってもらうのか、どこまでできたら完成なのか。どのファイルが正本で、どう検収するのか。ここを握る必要があります。
AIが優秀になればなるほど、人間の仕事は消えるのではなく、判断する場所が変わるのかもしれません。
ムカついたので、Codexともう一度向き合った
ここで終わると、ただの敗北です。
AI事務所キットを作っていたはずなのに、自分がAIの作業員になっていた。これはこれで、かなり味わい深い話です。ただ、味わい深いだけで終わるのも、腹が立ちます。
しばらくして、普通に自分にムカつきました。何をしているのか分からないまま、言われるがままに手を動かしていた。それは仕事ではなく、作業だった。
Codexの作業員ではなく、ディレクターへ戻る
だったら、もう一度こちら側に戻るしかありません。AIに指示される側ではなく、AIに指示する側へ。作業員ではなく、ディレクターへ。
そこで、改めて頭の中を整理しました。何を作り、誰のために作り、どこまでできたら完成なのか。Codexに何を任せて、自分は何を判断するのか。そこをもう一度、握り直しました。
そして、改めてCodexと向き合いました。
向き合った、というより、戦いました。
相手はAIです。でも、なぜか気分は河原の果たし合いです。三度笠をかぶった浪士が、ノートPCを前にして、ZIPとmanifest.jsonを相手に刀を抜いている。
だいぶ絵面はおかしいです。
でも、今度は違いました。
言われるがままではなく、こちらが目的を決める。商品名を決める。対象者を決める。完成条件を決める。そのうえで、Codexに作らせる。
ここで、ようやく感覚が戻りました。私はCodexの手足ではなくなりました。Codexを手足にして、商品を作る側に戻りました。
勝った。
少なくとも、その日はそう思いました。
Codexで「アプリなんて作れない」と思っていた人のためのキットを作った
そして作ったのが、これです。
アプリなんて作れないと思っていた人のための AI業務ツール制作キット
名前は長いです。でも、誰のためのものかは分かります。
アプリなんて作れない。コードなんて分からない。でも、自分の仕事を少し楽にする小さな業務ツールなら作ってみたい。そういう人のためのキットです。
勝った。少なくとも、その日はそう思った
ここで大事なのは、いきなり立派なアプリを作ることではありません。自分の仕事を分解し、AIに伝わる仕様にし、Codexに作らせ、人間が確認する。この流れを、非エンジニアでも踏めるようにすることです。
つまり、AIに丸投げするキットではありません。AIに仕事を任せるための、発注・制作・検収のキットです。
大げさに言えば、ディレクターに戻ったのです。小さく言えば、ようやく人間に戻りました。
作業員になったこと自体は、悪い経験ではありません。むしろ、自分が作業員になったからこそ、購入者を同じ場所で迷子にしてはいけないと分かりました。
非エンジニア向けに必要なのは、コードの説明だけではありません。今どこにいて、何を作っていて、何を確認すればいいのか。その現在地を示すことです。
AI教室や講座で学ぶべきなのは、プロンプトだけではない
今回の体験で思いました。アフィリエイトで紹介するなら、AIツールそのものよりも、AI教室やAI講座の方が自然かもしれません。
なぜなら、問題は「ツールを知らないこと」だけではないからです。問題は、AIをどう仕事に入れるか、どこまで任せるか、どこから人間が判断するか、完成物をどう確認するか。ここです。
まず本で全体像を掴みたい方へ
AIを仕事に使うには、プロンプトだけでなく、目的設定、作業の分け方、成果物の確認方法を知っておく必要があります。いきなり講座に申し込む前に、まず生成AI・ChatGPTの仕事術に関する本で全体像を掴むのも一つです。
非エンジニアこそ、現在地を見失わない地図がいる
プロンプトだけなら、ネットにいくらでもあります。でも、実際に業務や商品づくりに入れると、急に別の力が必要になります。AIに何を頼み、AIが出したものをどう確認し、どこで止め、どれを正本にするのか。ここを知らないまま進むと、AIを使っているつもりで、いつの間にかAIに使われます。
非エンジニアにとって、一番怖いのはコードそのものではないと思います。怖いのは、自分がいま何を作っているのか分からないまま、AIの指示通りに手だけ動かしている状態です。
これは、かなりしんどいです。作業は進んでいるのに、理解が進んでいない。ファイルは増えているのに、確信は増えていない。ZIPはできているのに、心は解凍されていない。
なかなか味わい深いです。
CodexでAIに使われないために、ディレクターに戻る
今回、よく分かりました。
AIを使うことと、AIに使われることは違います。AIに言われるがまま手を動かしていると、たしかに何かは完成します。でも、それは自分の仕事ではなく、AIの作業を手伝っているだけかもしれません。
大事なのは、目的を握ることです。誰のために、何を、どこまで作るのか。どこをAIに任せ、どこを自分が判断するのか。ここを握っているとき、人間はディレクターです。
ここを手放した瞬間、人間は作業員になります。
地図を作る者、遭難。でも戻ってきた
私は一度、見事に作業員になりました。AI事務所キットを作っていたはずなのに、最初に構築されたのは、AIの指示に従う自分でした。
地図を作る者、遭難。
なかなか味わい深いです。
でも、遭難したままでは終われません。頭を整理し、目的を握り直し、もう一度Codexに向き合う。そこでようやく、AIを手足にする側へ戻れました。
そしてできたのが、「アプリなんて作れないと思っていた人のための AI業務ツール制作キット」です。
AI時代のものづくりは、たぶんここからです。AIに作らせる。でも、AIに任せきらない。作業員になるな。ディレクターに戻れ。
あっしには関わりのねぇことでござんす。
……と言いたいところですが、今回ばかりは関わりました。
かなり関わりました。
しかも、最後は勝ちました。
後日談：ディレクターに戻るために必要だったのは、仕様書だった
このあと、もう一つ気づいたことがあります。
CodexでAI業務ツールを作るとき、最初に必要だったのはコードの知識ではありませんでした。
必要だったのは、仕様書でした。
誰が使うのか。何を入力するのか。何を保存するのか。何を出力するのか。どこまでできたら初版として合格なのか。
ここを決めずにCodexへ頼むと、AIは頑張ってくれます。ただし、こちらが思っていたものとは違う「それっぽい何か」ができます。
つまり、ディレクターに戻るために必要だったのは、AIへの気合いではなく、AIに渡す図面でした。
この後日談は、別の記事「アプリなんて作れないと思っていたら、最初に必要なのはコードじゃなく仕様書だった話」で詳しく書きます。
なお、AIやCodex以前の段階でも、ブログやWordPressまわりでは普通に迷子になりました。WordPress、SSL、サブドメインで詰まった話は、別記事「WordPressを入れるだけなら簡単だった。でもSSLとサブドメインで普通に迷子になった話」にも書いています。
参考：Codexについては、OpenAIの公式ページでも紹介されています。OpenAI Codex
関連記事として、この後日談にあたる「アプリなんて作れないと思っていたら、最初に必要なのはコードじゃなく仕様書だった話」、AIでホームページを作ろうとして問い合わせフォームで詰まった話、小さく稼ぐ前に売る場所と流れで手が止まった話も、同じ「AIに任せる前に人間が設計を握る」系の記録としてつながります。
