Codexで社内ツールを作る方法｜非エンジニア向け
「業者に頼むほどではないが、毎回手作業でやっている社内の集計や確認作業を、自分たちで小さなツールにできないか」——そう感じている中小企業の経営者や個人事業主は少なくありません。
結論から言うと、Codex（OpenAIのAIコーディング支援ツール。日本語の指示でコードを書いてくれる）を使えば、プログラミングを書けない人でも社内ツールの「たたき台」を作るところまでは現実的に届きます。ただし、丸投げではうまくいきません。人が要件と設計を固め、Codexに「作る作業」をやらせるという役割分担が前提です。
株式会社Fyveは、中小企業に月額でAI活用を伴走する立場から、この「社内ツール作り」を何度も現場で見てきました。私が本記事でお伝えするのは、非エンジニアが社内ツールを作るときの現実的な進め方と、つまずきやすい落とし穴です。
Codexで社内ツールを作るとはどういうことか
まず誤解を解いておきます。「社内ツールを作る」と聞くと、本格的なシステム開発を想像するかもしれませんが、ここで扱うのはもっと小さいものです。チームが繰り返し使う、業務に密着した道具のことを指します。
Codexは全ChatGPTプラン（無料からEnterpriseまで）に同梱されており、コマンドライン版（CLI）はMac・Windows・Linuxで動きます（出典: OpenAI公式 Codexクイックスタート）。日本語で「こういう画面を作って」「この計算をするツールにして」と頼むと、Codexが実際のコードを書いて動く状態まで持っていってくれます。
特に注目したいのが公式の「Sites」機能です。Codexはダッシュボード、予定管理、レビュー用の作業画面、案件ボードといった対話的なツールやアプリを生成し、ワークスペース内でURLとして共有できるとされています（出典: OpenAI公式 Codex for every role）。つまり、自分で作ったツールを「このURLを開いて使って」とチームに渡せるわけです。
「自動化」と「ツール化」は別物
混同しやすいのですが、毎日の定型処理を裏で自動で流す「自動化」と、人が画面を開いて操作する「ツール化」は別の話です。
- 自動化: 決まった集計やファイル処理を、人が触らずに定期実行する
- ツール化: 担当者が画面を開き、数字を入れたり一覧を見たりして判断に使う
本記事のテーマは後者です。営業状況が一目で分かるダッシュボード、案件の進み具合を共有するボード、見積もりの前提を計算する入力画面——こうした「みんなが開いて使う道具」を、非エンジニアが手元から立ち上げる、というのがゴールです。
非エンジニアでも作れる社内ツールの具体例
実際にどんなものが作れるのか、現実的な範囲でイメージを示します。いずれも「最初から完璧」を狙わず、まず動くたたき台を出して、使いながら直していくのが前提です。
- 営業・売上ダッシュボード: 手元の表データを読み込み、今月の数字や進捗をグラフで一覧表示する画面
- 案件・タスクの共有ボード: 誰が何を抱えているか、どこで止まっているかを可視化する画面
- 入力チェックツール: 見積もりや申込の前提条件を入れると、漏れや矛盾を指摘してくれる簡易フォーム
- 社内向けの小さなコマンド: 繰り返すデータ変換やレポート出力を、一行打つだけで実行できる道具
X（旧Twitter）上でも、日本語で「営業ダッシュボードを作って」と頼んで社内向けの画面を作り、URLでチームに共有したという報告が出ています（出典: X上の利用報告）。なお「営業15名の日次レポート作業を非技術チームが自動化した」といった具体的な人数・時間の数字を挙げる解説記事もありますが、これらは第三者の解説ベースで公式の裏付けは取れていないため、参考程度に捉えるのが安全です。
失敗しない作り方の「型」
ここが本記事の核心です。Codexは優秀ですが、確認をせずに自分の仮定でどんどん進めてしまう性質があります。要件が曖昧なまま投げると「動くけれど意図と違う構造」のものが出てきて、かえって手戻りが増えます（出典: X上の指摘）。これを防ぐ進め方が「型」です。
役割分担を決める — 人が設計、Codexが実装
全部をCodexに丸投げしないことが鉄則です。順番はこうです。
- 要件整理（人）: 何のための道具か、誰が使うか、入力と出力は何かを言葉にする
- 設計確認（人とCodex）: 作る前にCodexに段取りを説明させ、認識のズレをここで潰す
- 実装（Codex）: 固まった設計に沿ってコードを書かせる
- レビュー（人）: 出てきたものを必ず人がチェックしてから使う
Codexを「考える主役」ではなく「実行役」に徹させると、出力が安定します。Codexには事前に計画を立てて確認する進め方（いわゆるプランモード）があるので、いきなり作らせず、まず段取りを見せてもらってから着手するのが安全です。
具体的にどう頼むか — 指示文の例
抽象的な話だけでは動けないので、実際の頼み方を示します。たとえば営業の数字を見る画面が欲しいなら、Codexにこう伝えます。
- 「手元の売上データ（CSV）を読み込んで、今月の合計・先月比・担当者別の内訳を表示する画面を作りたい」
- 「まず作る前に、どんな手順で進めるか段取りを説明してほしい」
- 「金額の計算ロジックは、後で私が確認できるように分かりやすく分けてほしい」
ポイントは、いきなり「作って」ではなく「段取りを説明して」を挟むことです。ここで出てきた説明を読み、自分の意図と違えば「そこは違う、こうしたい」と日本語で返すだけで軌道修正できます。専門用語を使う必要はなく、目的と確認したいことを普通の言葉で伝えれば十分です。
社内のルールを先に文書で固定する
Codexには、プロジェクトの決まりごとを書いた説明書を最初に読ませる仕組みがあります。公式にはAGENTS.mdというファイルでプロジェクトの規約を定義できます（出典: OpenAI公式 Codex CLI機能）。
ここに「社内で使う言葉の統一」「ファイルの置き場所」「動かす前に必ず確認すること」といった前提を書いておくと、Codexが毎回それを踏まえて作業します。非エンジニアにとっては「口頭で毎回説明する手間が消える」という効果が大きいです。専門知識ではなく、社内の決めごとを日本語で書くだけで構いません。
社内のデータや仕組みとつなぐ
社内ツールが本当に役立つのは、自社のデータや仕組みとつながったときです。CodexにはMCP（外部のツールやデータ源とAIを安全につなぐ共通の仕組み）という拡張があり、社内のAPIや既存システムをCodexから呼べるように登録できます（出典: OpenAI公式 Codex CLI機能）。
さらに、よく使う社内の手順を「Skills」としてパッケージ化したり、自社の業務システムにCodexを組み込む「SDK」も公式に用意されています（出典: OpenAI公式 Codex SDK）。ここまで来ると非エンジニア単独では難しくなりますが、「最初のたたき台は自分で、本格的な接続は専門家と」という分担で十分に前に進めます。
この設計や運用の考え方は、Codexの全体像を押さえておくと格段に進めやすくなります。
非エンジニアがつまずく落とし穴
現場で繰り返し見てきた、典型的なつまずきと回避策をまとめます。
最初から完全自動化を狙わない
いきなり「全部おまかせで完成」を目指すと、たいてい失敗します。まず人が手動で一度通してみて、流れが固まってから自動の範囲を広げるのが定石です（出典: X上の指摘）。最初の一回を人が確認しながら通すこと自体が、要件のズレを発見する一番確実な方法になります。
指示を細かく出しすぎず、しかし曖昧にもしない
長い説明をだらだら書くと、Codexが扱う情報が膨らみすぎて精度が落ちます。一方で曖昧すぎると見当違いのものが出ます。コツは「目的・入力・出力・守ってほしい条件」を箇条書きで簡潔に渡すことです。一つのツールは一つの役割に絞り、欲張らないほうが結果的に早く完成します。
人のチェックポイントを必ず残す
AIが出したものをそのまま本番に使うのは禁物です。エラー監視のような場面でも、AIが修正案を出し、反映前に必ず人がレビューする運用が推奨されています（出典: X上の運用例）。社内ツールも同じで、数字の計算ロジックや顧客に関わる処理は、必ず人が目視で確かめてから配布してください。
社内ネットワークの制約に注意
会社のネットワークでは、通信制限や権限設定によってCodexがうまく動かないことがあります。これは環境依存の話で、社内のネットワーク担当に確認が必要なケースです。まずは制約の少ない環境で試し、動くことを確かめてから社内展開するのが安全です。
中小企業が今日から踏み出す現実的な手順
大がかりに考える必要はありません。最初の一日でやることはシンプルです。
- 痛い手作業を棚卸しする: 毎週・毎月繰り返している面倒な作業を書き出す。最初に一覧化するだけで、何をツール化すべきかが見えます
- 一番小さい一つを選ぶ: 失敗しても痛くない、影響範囲の狭い作業から始める
- たたき台を作って一度使う: 完璧を求めず、まず動くものを出して自分で使ってみる
- 使いながら直す: 不満が出たところだけCodexに修正を頼み、少しずつ育てる
X上でも、最初の一日で痛い手作業を棚卸しし、繰り返すものから小さく道具化していくことで大きな時短につながった、という報告があります（出典: X上の実践報告）。Codexは「ゼロから何でも生み出す魔法」ではなく、「固まった社内の手順を高速で形にする実行エンジン」と捉えると、期待値を外しません。
導入の入口としてのCLIの基本操作に不安がある場合は、こちらも参考になります。
まとめ — 設計は人、実装はCodex
非エンジニアでもCodexで社内ツールのたたき台を作ることは、もはや現実的です。鍵は丸投げしないこと。要件と設計を人が固め、社内のルールを文書で渡し、出てきたものを人がレビューする——この役割分担を守れば、Codexは頼れる実行役になります。
まずは痛い手作業を一つ選び、小さく作って使ってみてください。一つ動かせれば、二つ目からは驚くほど速く回り始めます。私たちが現場で見てきた限り、最初の一歩を踏み出した会社ほど、その後の積み上がりが大きいというのが正直な実感です。
「Codex を自分で使いこなしたい」「自社の業務に組み込みたい」
── そんな方は、まず初回無料相談でお話ししてみませんか。
御社の業務に合わせたCodex導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。