プログラミングが得意じゃない私が、Codexを使って自分専用のツールを作るまでの話

「こういうツールがあったらいいのに」と思うことは、よくある。

競合5社の価格を毎週手動で調べているとき。複数のCSVを毎回コピペで統合しているとき。作業ログをExcelに手入力していて「もっと楽な方法があるはずだ」と感じているとき。頭の中に「こんなツールがあれば解決する」というイメージはある。でもそれを作れる技術がない。

エンジニアの友人に頼もうとしたこともある。でも「この程度の機能でエンジニアに頼むのは申し訳ない」という気持ちと、「どう説明すればいいかわからない」という壁があって、いつも「まあいいか」で終わっていた。

Codexで自分専用ツールを作り始めたのは、そういう積み重なった「まあいいか」へのうんざりから始まった体験だ。

結論から言うと、「プログラミングが得意でなくても、Codexを使えば自分専用のツールは作れる。ただし、知っておくべきことと、覚悟すべき壁がある」というのが正直な答えだ。

この記事では、実際に作った3つのツール、Codexとの開発プロセス、うまくいかなかった点、非エンジニアが個人開発でCodexを使う上のコツを、体験談として正直に書く。

「作りたいもの」はあるのに、「作る手段」だけがなかった

プログラミングができなくても、欲しいツールのイメージを持っている人は多い。ビジネスの現場で日々の非効率を感じているからこそ、「こうなればいい」という解像度が高い。それが武器になるとは、Codexに出会うまで思っていなかった。

プログラミングへの敷居が、見えないところにある問題

Progateや動画教材でプログラミングの基礎を学ぼうとしたことがある。変数・関数・ループは理解した。でも「学んだこと」から「作りたいものを作れる」になるまでの距離が、思った以上に遠かった。

PythonでCSVを読み込む方法はわかる。でも「自分のExcelファイルを読んで、特定の列を集計して、別のシートに出力する」という具体的な要件を実現するには、ライブラリの知識・エラー処理・ファイルパスの扱いなど、基礎の先にある層がいくつも必要になる。その層を独力で積み上げるのが難しかった。

Codexが変えたのは、この「基礎の先の層」を自分で積み上げなくていい、という点だ。「こういうことをやりたい」という要件を言語化できれば、Codexが技術的な実装を担ってくれる。

Codexが「とりあえず作ってみる」を可能にした

Codexとは、OpenAIが開発したAIコーディング支援エージェントで、自然言語の指示をもとにコードの生成・実行・修正を行うツールだ。2026年2月にはmacOSとWindows向けのアプリが公開され、複数タスクの並行処理や長時間プロジェクトの管理がしやすくなった（OpenAI公式発表）。

使い始めたときに感じたのは「とりあえず作ってみる」という行動が、Codexを使えばほぼゼロコストでできるという感覚だった。何かを作るとき、以前は「本当に作れるか？」という不安があった。今は「とりあえずCodexに言えば動くものが出てくる」というスタートラインが変わった。

Codexが非エンジニアにとってもたらした最大の変化は「作る技術がなくても、作りたいものを形にする入り口に立てる」ことだ。

Codexで実際に作った3つの自分専用ツール

実際に作ったツールを3つ紹介する。いずれも「エンジニアに頼むほどでもないけど、毎回手でやるのが面倒」という規模のツールだ。

ツール①：複数CSVを統合して集計するPythonスクリプト

毎月、部門ごとに別々のCSVで届く売上データを一つに統合して、商品カテゴリ別・担当者別の集計表を作る作業が月次の定番業務だった。4〜5枚のCSVをコピペで統合して、ExcelのSUMIF関数で集計する。慣れれば30〜40分の作業だが、毎月やるのが煩わしかった。

Codexへの指示は「複数のCSVファイルを読み込んで、商品カテゴリ列と担当者列でグループ化して売上合計を出し、Excelファイルに出力するPythonスクリプトを作って」というものだった。列の名称も具体的に伝えた。

最初に出てきたコードは、ファイルパスの指定方法が自分の環境と合わずエラーが出た。「このエラーが出た。ファイルはデスクトップの『月次データ』フォルダにある」と状況をそのまま伝えると、修正版が返ってきた。2回のやり取りで動くスクリプトが完成した。

完成したスクリプトを実行するとき、毎回Codexを使う必要はない。一度作ったスクリプトは自分のPCに保存してあるので、翌月はそのファイルを実行するだけだ。30〜40分の作業が2分以内に終わるようになった。

ツール②：複数ニュースサイトの更新を一覧表示するWebツール

業界情報を毎日チェックするために3〜4サイトを個別に開くのが習慣になっていた。Codexで実際にツールを作った事例（SIFCA、2026年）を見て「自分でも作れそう」と思い、試してみた。

指示は「指定した3つのニュースサイトのRSSフィードを読み込んで、最新記事のタイトル・日時・URLを一覧表示するシンプルなHTMLページを作って」というものだ。

最初の出力はシンプルすぎて日時の表示フォーマットが読みにくかった。「日時を『YYYY年MM月DD日 HH:MM』の形式で表示して」と追加指示したら即座に修正された。Figmaで作ったラフなデザイン画像を見せて「このレイアウトに近い形にして」と視覚的な指示をしたときも、Codexが意図を読んで実装してくれた（SIFCA事例を参考に試した方法）。

HTMLファイルをブラウザで開くだけで使えるシンプルなツールなので、特別な環境構築も不要だった。今では毎朝このページを開いて情報収集している。

ツール③：プロジェクト別の作業時間を記録するWebアプリ

フリーランス的な仕事をしていると、どのプロジェクトに何時間使ったかを把握することが重要だが、既存のタイムトラッキングアプリはオーバースペックに感じていた。「開始・停止ボタンがあって、プロジェクト名を選べて、日次・週次の合計が見られるだけのシンプルなもの」が欲しかった。

指示は「プロジェクト名を選択してスタート・ストップで時間計測できる、シンプルなWebアプリを作って。データはブラウザのローカルストレージに保存して、日付ごとの合計も見られるようにして」という内容だ。

これは3ツールの中で最も完成まで時間がかかった。UIの細かい動作（ボタンを押したときの見た目の変化、タイマーの表示フォーマット）に関して5〜6回の追加指示が必要だった。それでも1時間程度で動くものが完成した。「優秀な助手が横についているような感覚で、少しずつ改善されていく過程は楽しい体験だった」という表現を見かけたが（note.com/hitotsu_ai）、まさにそういう感覚だった。

3つのツールを作って共通して感じたのは、「作り始めの敷居が下がった分、どこまで作るかの判断が自分に委ねられる」ということだ。

Codexとの対話で「個人開発」が進むプロセス

「Codexがコードを書いてくれる」という説明は正しいが、「指示さえ出せば完成品が出てくる」という印象は少し違う。実際のプロセスは、もう少し対話的だ。

要件を言語化するところが最初の壁

Codexに指示を出す前に「自分が何を作りたいか」を言語化する作業が、意外と時間がかかる。「便利なツール」という曖昧な要件では、Codexも曖昧なものしか出せない。

私が作業時間記録アプリを作るとき、最初の指示は「作業時間を記録するアプリ」だった。出てきたものは確かに動くが、自分のイメージと違う部分が多かった。「プロジェクト名はドロップダウンで選びたい」「計測中はタイマーが動いて見えるようにしたい」「過去のデータを日付でフィルタリングしたい」という要件が、最初に言語化できていなかった。

この経験から、Codexに指示を出す前に「紙に書いてみる」習慣をつけた。必要な機能をリスト化して、「これがあれば他は要らない」という最小要件を決めてから指示を出すと、最初のアウトプットと自分のイメージのズレが減る。

「最小限で動くもの」から始める段階的な作り方

SIFCA（2026年）の事例でも「最小限の構成で動くものを最初に提案してくれ」という指示が有効だったと報告されている。これは私も同じ方法を試して効果を感じた。

最初から完成形を目指すのではなく、「まず動く最小版を作って、そこから少しずつ機能を足す」段階的なアプローチが、Codexとの個人開発では効果的だ。

具体的な流れはこうだ。まず「最小限の機能で動くものを作って」と指示してシンプルなバージョンを作る。動作を確認したら「この機能を追加したい」「この部分の見た目を変えたい」という追加指示を一つずつ出していく。一度に多くの変更を指示すると、どの変更が問題を起こしているかわからなくなる。

エラーが出ても、Codexと一緒に直せる

コードを実行するとエラーが出る。これは必ず起きる。以前の私なら「エラーが出た→諦める」だった。Codexを使い始めてから「エラーが出た→Codexに報告する→直してもらう」になった。

エラーへの対処で最も効果的だと感じた指示の形は「このエラーメッセージが出ています。私の環境は〇〇です。どうすれば直りますか？」だ。エラーメッセージをそのままコピーして貼り付け、自分の環境情報（OSの種類・Pythonのバージョン・ファイルの場所など）を補足すると、的確な解決策が返ってくることが多い。

育児しながらスマホのみで個人開発を進めた事例（kako351.dev）では「スキマ時間に少しずつ進められる」という点が強調されていた。Codexとのやり取りはテキストベースなので、まとまった時間がなくても少しずつ進められる。これも非エンジニアにとっての個人開発のハードルを下げている要因だ。

個人ツール開発でCodexを使う上での3つのコツ

3つのツールを作る中で気づいた、非エンジニアがCodexで個人開発を進める上での具体的なコツを整理する。

コツ①：完成形を絵や言葉で具体的にしてから始める

「便利なツール」という曖昧な要件では、Codexもアウトプットを絞り込めない。始める前に「このツールを使って最初にやる操作は何か」「画面に何が表示されていれば満足か」を具体的に言語化しておく。

Figmaやスケッチアプリで簡単な画面のラフ案を描いて、それを画像としてCodexに見せる方法も効果的だ（SIFCA事例）。「このラフに近い見た目で作って」という視覚的な指示は、文章だけより意図を正確に伝えられる。Codexはアップロードした画像を参照してUIを実装できる。

事前に「必要な機能リスト」と「あったらいいけどなくてもいい機能リスト」を分けておくと、最小版から始めた後の優先順位がつけやすい。

コツ②：一度に全部作ろうとしない

「一つの指示で完成品を作ろう」とするのが、最も失敗しやすいパターンだ。複雑な要件を一度に指示すると、コードが長くなり、どこに問題があるかの判断が難しくなる。

機能を分割して、一つずつ動作確認しながら進める。「今日はCSVを読み込む部分だけ」「明日は集計ロジックを追加する」という分割が、結果的に完成が早い。途中でうまくいかなくなったとき、どこまで戻ればいいかがわかりやすくなる。

スマホで開発した事例（kako351.dev）でも「ユーザー名表示→ログアウト機能」のように、小さな機能を一つずつ実装していく手順が取られていた。このアプローチは特に非エンジニアの個人開発に向いている。

コツ③：動いたらすぐGitHubでバックアップを取る

動くバージョンができたら、必ずバックアップを取る習慣が重要だ。「もう少し機能を足したい」という気持ちで追加の指示を出したら、なぜか動かなくなった、ということは起きる。戻れる状態を作っておくことが、安心して改良を続けるための基本だ。

GitHubを使えば、バージョン管理ができる。動くバージョンをコミットしておけば、何かあったときにそこまで戻せる。育児中スマホ開発の事例（kako351.dev）では「GitHub→Cloudflare PagesでのPR・プレビュー機能により進捗管理も容易だった」と報告されている。GitHubに慣れていない場合は、少なくとも「動いたときのコードをテキストファイルにコピーして別のフォルダに保存」というアナログな方法でも、戻れる場所が確保できる。

正直に言う：非エンジニアがCodexで作るの限界もある

「誰でも何でも作れる」という話ではない。SIFCA事例でも「非エンジニアでも一定の知識が必要」という指摘があり、私もこれに同意する。

記事サムネイル画像の表示実装で多くのやり取りが必要になり、「試行錯誤するCodexの提案に自分がもっと上手く指示を出してあげれたら…と、もどかしい気持ちでした」という体験（SIFCA）は、私にも似た経験がある。

非エンジニアがCodexで作るときにぶつかりやすい限界は3つある。

• 何が起きているかわからないエラー　エラーメッセージを見ても「どんな状況を伝えればいいか」がわからないと、Codexへの情報提供が不十分になる。「何かおかしいのはわかるが、何がおかしいか言語化できない」状態はデバッグが難しい
• セキュリティ・本番環境への対応　「自分だけが使うローカルツール」なら問題が少ないが、「他の人に使ってもらう」「本番環境に置く」となると、セキュリティの考慮が必要になる。Codexが生成したコードにセキュリティ上の問題があっても、知識がないと気づけない
• 複雑なシステム連携　外部APIとの接続・認証フロー・データベース設計が絡む複雑なシステムは、非エンジニアがCodexだけで完成させるのが難しくなる。育児中スマホ開発事例でも「長時間デバッグや複雑なリファクタには限界」と認めていた（kako351.dev）

Codexは「プログラミングができなくても作れる」のではなく「プログラミングへの敷居を大幅に下げてくれる」ツールだ。この違いを理解することが、挫折しない個人開発の出発点になる。

よくある質問（FAQ）

まとめ

プログラミングが得意でない私が、Codexを使って自分専用のツールを作った体験から言えることは、「作れる。ただし、イメージを言語化する力と、対話を続ける根気が必要だ」ということだ。

SIFCA（2026年）が指摘した通り「アイデアの面白さがこれからもっと大事になる」という言葉が、この体験を通じてリアルに感じられた。技術的な実装はCodexに任せられる分、「何を作るか」「なぜ作るか」という発想の部分が、個人開発の価値を決める軸になった。

• 完成形のイメージを具体的に描いてから始める　紙に書いても、ラフ画像でも。Codexへの指示の質はここで決まる
• 最小版から始めて、少しずつ機能を足す　一度に全部作ろうとせず、動く状態を積み重ねていく
• 動いたらすぐバックアップ　GitHubか、少なくともテキストファイルのコピーで「戻れる場所」を作っておく

「こういうツールがあればいいのに」という感覚は、使えるアイデアだ。そのアイデアをCodexへの指示に変換する練習を、今日から始めてみてほしい。