※本記事には広告が含まれます。
非エンジニアでもCodexを仕事に使えます。 ただし、最初に選びたいのは「AIなら作れそうなもの」より、自分で出来を確かめられる仕事です。
僕自身、プログラミング専業のエンジニアではありません。普段はWeb編集・制作の実務に携わっています。コードを一から書く専門家ではなくても、原稿や構成の良し悪しを判断する知識は持ち込めました。
この記事では、WordPress（ブログやWebサイトを管理・更新する仕組み）の作業で進められたことと残った課題をもとに、何から試し、どの知識を補うかを整理します。独学を続ける場合と、教材や講座を検討する場合の分かれ目も紹介します。
1. 非エンジニアでも使える。まず自分で確かめられる仕事から
最初の題材には、出力された結果を元資料や画面と見比べ、目的に合っているか判断できる仕事をおすすめします。作れるものの大きさより、自分で確かめられる範囲を目安にするんです。
編集や制作の「既存の目」を持ち込めば判断できる
非エンジニアとはいえ、Webの編集者やライター、ディレクターとして実務をされている方なら、すでに大きな強みを持っています。それは「原稿の構成が崩れていないか」「日本語として自然か」「指示通りの見出し構造になっているか」を見極める目です。
たとえば、Markdown形式の原稿ファイルを読み込ませて、
- 見出しの階層（H2やH3）に重複や矛盾がないかをチェックさせる
- 構成案に対して、本文で説明が抜け落ちている論点を洗い出させる
- 指定した文字数やトーン＆マナーに沿っているかを照合させる
といった作業なら、原稿や構成について持っている知識で、AIの指摘や修正案を確かめられますよね。
題材を選ぶ目安は、目的と欲しい結果を説明できること、元資料や画面と照合できること、元に戻せる範囲で試せることの3つです。僕にはWeb実務の経験があったので、Webもパソコンも初めての人に、同じ容易さでできるとまでは言えません。
公式でも「非開発職の業務利用」が紹介されている
OpenAI：Codex for every role, tool, and workflow では、OpenAI社内の非技術職による社内アプリの構築、経営向け資料の作成、ダッシュボードの構築などの活用例が紹介されています。
2. WordPressで進められたことと、まだ終わっていないこと
僕が2026年10月6日に共有したWordPressの作業報告では、記事の下書き化とテスト環境への初回反映まで進んでいました。ここからは、報告当時にできたことと、まだ終わっていなかったことを分けて紹介します。
作業報告の時点で進められたこと
- 記事原稿の下書き移行：2記事分の原稿をWordPressへ移しました。初回は管理画面から下書きとして入稿しました。
- 表示用ファイルのテスト環境反映：サイトの表示に関わる9個のファイルを、テスト環境へ初回反映し、ファイルの一致を確認しました。
これは記事の本文制作までCodexだけで完了したという話ではありません。まずは用意した原稿を下書きへ移し、表示用ファイルを反映できた段階です。
コード以外でつまずいた「接続」と「制限」の壁
一方で、サーバーの接続設定やアクセス制限でつまずきました。コードを書くこと以外にも、作業環境の条件を理解する必要があったんです。
具体的には、テスト環境へファイルを同期しようとした際、以下の2点でつまずきました。
- SSH鍵の形式：SSHはサーバーへ接続して操作するための仕組みです。その認証に使う鍵の形式が接続時の課題になりました。
- レンタルサーバーの国外アクセス制限：Xserver側のアクセス制限が接続の妨げになっていました。
鍵の形式とアクセス制限を見直し、設定変更後には接続できました。ただし、アクセス制限の変更は環境ごとの判断が必要です。全員が制限を解除すればよい、という手順として紹介しているわけではありません。
報告時点で「まだ終わっていなかったこと」
GitHubはファイルの変更履歴を管理するサービスです。非公開の保存場所と自動反映の設定は用意しましたが、次の更新でも正しく動くかは、報告時点では未検証でした。
また、外部からWordPressを操作する窓口であるREST APIを使った入稿は、Basic認証というアクセス制限との競合が未解決でした。そこで初回は、管理画面から進めています。
| 作業項目 | 2026-10-06時点の状態 | 補足と当時の判断 |
|---|---|---|
| 原稿のWordPress下書き化 | 2記事完了 | 初回は管理画面から手動入稿。全自動ではない |
| 表示用9ファイルの反映 | テスト環境で初回反映一致 | 次回更新での自動反映確認は別に残る |
| サーバーへのSSH接続 | 設定変更後に接続成功 | SSH鍵形式の調整と国外アクセス制限の見直しで解決 |
| GitHub連携の自動反映 | 設定作成済み・次回自動起動は未検証 | 次回コミット時の実動作確認は持ち越し |
| REST APIでの継続入稿 | 未実施 | Basic認証との競合が未解決 |
| 本番環境への反映 | 未実施 | この作業報告では掲載まで進んでいない |
ここで分けて考えたいのが、「一度反映できた」と「次も継続して使える」です。初回は手作業でも目的へ進めます。繰り返し任せたい段階になったら、次の更新でも動くことを別に確かめる必要があります。
3. コード以外に必要だったのは、依頼・確認・変更範囲の整理
Codexを使っていて思い通りにいかないとき、「もっと長いプロンプトを書けば解決するんじゃないか」「難しい専門用語を使って細かく命令すればいいのかな」と思いがちですよね。
先に整理したいのは、依頼の目的、参照する材料、守るべき制約、どうやって確かめるかです。接続条件が原因なら、指示を長くするだけでは先へ進めません。
OpenAIが公式に推奨するプロンプトの原則
OpenAI：Prompting の「Prompting Codex」では、望む挙動、対象コードや再現手順、制約、検証方法を伝える考え方が示されています。原稿やWeb制作へ当てはめるなら、次のように整理できます。
- 望む挙動（目的）：何を作りたいのか、どのような動作を期待しているのかを明確にする。
- 対象コードや再現手順（材料）：どのファイルを読み、どの情報を元に作業すべきかを具体的に指定する。
- 制約条件：やってはいけないこと、変更してはいけない範囲、守るべきルールを指定する。
- 検証方法：作業が終わったあと、どのような基準やテストで成否を確認するかをあらかじめ決めておく。
今の困りごとから、先に確かめるものを選んでみてください。
| 今困っていること | 先に整理・確認すること |
|---|---|
| 頼んだものと違うものが出る | 目的、使う資料、完成の条件 |
| 余計なところまで変わる | 変更する場所と、維持する場所 |
| 修正の良し悪しがわからない | 元資料・画面・変更前後の差との照合 |
| 接続や公開で止まる | 接続元と接続先、認証・公開先の条件 |
ルール化と変更範囲の絞り込みで安全性を高める
同じ作業を繰り返すようになったら、共通の指示や操作範囲も整理しておくとよいでしょう。
- 指示の共通ルール化（AGENTS.md）：繰り返し使う前提や、守るべき文体などをまとめておく方法です。
- 承認モードと権限の管理：操作を許す範囲と、承認の扱いを確認します。許可範囲内での変更は、毎回確認を求められるとは限りません。
AGENTS.mdは仕事の指示、権限設定は操作を許す範囲です。指示文だけで技術的なアクセス制限を設定できるわけではありません。
4. 独学は、小さな依頼から同じ作業の再利用へ進める
独学では、小さく頼む→出来を確かめる→同種の別作業で試す→必要なら連携・公開へ進む、という順番を提案します。僕がこの順番通りに学んだ記録ではなく、実務のつまずきを踏まえた進め方の案です。
独学を進める4つのステップ
- 小さく頼む：秘密情報を含まない検証用の資料で、ファイルの確認や箇条書きの整理などを一つ依頼します。欲しい結果、使ってよい資料、変更しないものを説明できることが目安です。
- 元資料や画面と照合する：出力と元資料を見比べます。どこがよく、どこが違うかを具体的に説明できるようになったら、狭い範囲で修正を頼みます。
- 同種の別作業で再利用する：別の原稿や資料でも同じ作業を試します。一度の成功だけで再利用できると判断せず、必要だった指示だけ残します。
- 必要になった場合だけ連携・公開へ進む：継続更新や外部連携が仕事に必要になったら、接続先、費用、扱う情報、戻し方、確認する人を整理して進めます。
原稿やファイルの整理だけで目的を達成できるなら、ステップ4へ進む必要はありません。使う範囲に合わせて、必要な知識を補っていけばよいんです。
まず試してみてほしい依頼文の具体例
原稿の点検を題材にするなら、例えば次のように頼めます。これは説明用の例で、効果を測定したプロンプトではありません。
この検証用フォルダの原稿.mdを読み、見出しの重複と説明の抜けを指摘してください。
まず指摘と修正案だけを出し、まだファイルは変更しないでください。
本文にない事実や数値は補わず、判断できない箇所はそのまま示してください。対象の資料、まだ変更しないこと、事実を補わないことを分けて伝えています。返ってきた指摘は原稿と見比べ、「確かに抜けている」「ここは意図通りなので直さない」と判断してください。
この指示だけで他の場所へのアクセスや事実の補完を技術的に防げるわけではありません。指示を出したあとも、結果の確認は必要です。
5. 独学・買い切り教材・相談付き講座は、つまずき方で選ぶ
つまずいたからといって、すぐに講座へ申し込む必要はありません。大切なのは、足りないのが操作の情報なのか、学ぶ順番なのか、個別環境を見てもらう支援なのかを分けることです。
4つの学び方の特徴と選び方
次の表は、今の困りごとから学び方や支援を比べるための目安です。
| 今の状態 | まず検討する方法 | 選ぶ前に確認すること |
|---|---|---|
| 目的が一つで、調べながら次へ進める | 独学を続ける | 情報の更新日と自分の利用環境 |
| 作りたいものは決まっているが、一連の手順がわからない | テーマを絞った買い切り教材 | 演習の到達点、OS・画面の一致、更新状況、質問対応の有無 |
| 複数の知識がつながらず、学ぶ順番や質問できる場がほしい | 相談機会を含む講座 | 学習内容、相談できる範囲・方法・時間、費用 |
| 本番サイトの不具合など、期限のある個別問題を解決したい | 専門家による個別支援 | 現在の環境を見てもらえるか、責任範囲と費用 |
講座は学ぶための選択肢です。急ぎの個別トラブルを解決したい場合は、その環境を見て対応できる支援かどうかを確かめてください。
作りたいものがまだ曖昧なら、まず小さな題材を一つ決めるところからで十分です。公式情報や試行で先へ進める間は、独学を続ける選択もあります。
6. 講座を検討するなら、操作以外に何を学べるか確かめる
Web制作や公開、API連携まで順序立てて学びたいなら、カリキュラムが用意された継続学習サービスも候補になります。
ただし、検討する際は「AIの操作方法」だけでなく、「その操作を使って、実際のWeb制作や業務利用のどこまでを学べるのか」を必ず確認するようにしてください。
体系的な学びの選択肢「DMM 生成AI CAMP 学び放題」
その選択肢の1つとして挙げられるのが、「DMM 生成AI CAMP 学び放題」です。
「Codexマスターコース」の公開カリキュラムでは、基本操作に加えて次の内容が案内されています。ここでは受講レビューではなく、公開情報を紹介しています。
- デスクトップアプリの基本操作と承認モード
- Web制作と、GitHub・Cloudflare Pagesを使った公開
- Gemini APIとの連携
- AGENTS.mdの活用、議事録の整形などの業務利用
（参照：DMM：Codexマスターコース）
操作の次にある制作・公開・連携を学びたい人は、自分に足りない項目が含まれるか照合してみるとよいでしょう。ただし、WordPress・SWELL・Xserverで起きる個別の問題まで扱えるとは確認していません。自分の環境や質問に対応しているかは、別に確認する必要があります。
料金体系とサポートオプションの注意点
2026年10月7日時点の公式コースページでは、月額プランは次のように案内されています。
- 月額プラン：月額14,800円（税込16,280円）
（最低契約期間の縛りなしと案内されています。長期の一括払いプランとは異なります）
ここで確認しておきたいのは、1対1の面談や個別相談が、すべてこの月額料金に含まれているわけではないという点です。
1対1の学習設計や面談、チャットサポートを含む「パーソナルサポート」は、別料金の月額オプションです。必要な相談の範囲・方法・追加費用を確認しましょう。CodexやAPIなど、受講料以外にツール利用料が必要かも確認しておきたいところです。料金・サポートの公式案内
まずは無料セミナーで「自分に合うか」を確かめる
DMMヘルプ：無料セミナーとは によると、この無料セミナーは入会を検討している方向けにカリキュラムの詳細を紹介し、リアルタイムでの質疑応答を受け付けているオンライン説明の場です。
成果物例の紹介もあり、学習のイメージを確かめる入口になります。個別のパソコンやサーバーを診断する無料の技術相談とは区別して考えてください。
公式ページやセミナーで内容と費用を確認し、継続して学ぶ内容が自分の目的に合えば、入会を検討する流れです。セミナーへの参加は入会の必須条件ではありません。
独学を続けるなら、まずは検証用の原稿を一つ選び、上の依頼例で点検を頼んでみてください。返ってきた指摘を元資料と見比べるところまでを、今日の一つの作業にしてみましょう。