タグ: 生成AI

PR：この記事は、CodexでAI業務ツールを作った実体験をもとに書いています。広告・アフィリエイトリンクを含む場合があります。

CodexでAI業務ツールを作っていたら、気づけば自分がAIの作業員になっていました。

これは、非エンジニアがCodexでAI業務ツールや小さなアプリ制作キットを作ろうとして、ZIP、HTML、JavaScript、manifest、README、検収ファイルの海で普通に迷子になった記録です。
もともとの入口はAI事務所キットでしたが、この記事の主役はそこからCodexへ踏み込んだ瞬間に起きた「作業員化」です。

先に結論を書くと、Codexはすごいです。
ただし、目的、完成条件、正本ファイル、検収手順を人間側が握っていないと、AIに作らせているつもりで、自分がAIの指示どおりに動く作業員になります。

AIを使う側に残るには、プロンプトだけでは足りません。必要なのは、AI制作ディレクションでした。

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が出したものをどう確認し、どこで止め、どれを正本にするのか。ここを知らないまま進むと、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に任せる前に人間が設計を握る」系の記録としてつながります。