1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@pan_sljin株式会社スピードリンクジャパン

初心者がCodexを使い始める前に、まずやる5つのこと

1
Posted at

はじめに

コーディング未経験者として、自分のアプリを開発するために、Codexを使い始めました。

ChatGPTやGPT-5.5などのモデルは、こちらの要望をかなり正確に汲み取ってくれます。言語化や補足も得意なので、考えを整理したり、やりたいことを形にしたりする時はとても便利です。

一方で、Codexのようなエージェント（agent）の動きを完全に理解しきれない初心者として、不安もありますし、ベテランのように効率よくエージェントを使い回せてない自覚があります。

同じ料金を払った以上、お得気分で使いたいですよね。

そのために記事や公式ドキュメントを調べてみたら、

:white_flower:初心者が最初にやっておくとよさそうな5つのこと:white_flower:を意識して取り組むようになりました。

  1. 先に AGENTS.md を書く
  2. 権限（Permissions）を広げすぎない
  3. 重要ファイルを先に決める
  4. タスクは具体的に書く
  5. 完成後に生成過程と差分を見る

1. 先にAGENTS.mdを書く

最初にやることは、Codexにプロジェクトのルールを伝えることです。

Codexでは、AGENTS.md というファイルに作業ルールを書けます。これは、Codexに対するプロジェクト専用の説明書のようなものです。

たとえば、最初はこのくらいで十分だと思います。

# AGENTS.md

## Rules

- 作業前: 変更予定ファイルを説明
- 変更禁止: `.env`, `.env.local`, database migration
- 依存追加: 事前確認
- 作業後: 変更内容と確認方法を報告
- 不明点: 先に質問

AGENTS.mdって、実際どう作るの？

ここでつまずきやすいのは、「AGENTS.mdを書きましょう」と言われても、そもそもどう作るのか分からないことです。

方法は2つあります。

1つ目は、自分でプロジェクトフォルダに AGENTS.md というMarkdownファイルを作る方法です。

my-app/
├─ src/
├─ package.json
├─ README.md
└─ AGENTS.md

複数の作業で共通ルールを使いたい場合は、もっと上のフォルダに置くことも考えられます。ただし最初は、全体フォルダではなく、今作業しているプロジェクト単位で作る方が管理しやすいです。

2つ目は、Codexに作ってもらう方法です。

例:

AGENTS.md案を作成。まだファイル作成しない。

含めるルール:
- 作業前: 変更予定ファイルを説明
- 変更禁止: .env, .env.local, database migration
- 依存追加: 事前確認
- 作業後: 変更内容と確認方法を報告
- 不明点: 先に質問

次にファイル作成まで頼む場合:

この内容で、プロジェクト直下にAGENTS.mdを作成。

2. 権限（Permissions）を広げすぎない

次に大事なのは、最初から権限（Permissions）を広げすぎないことです。

Codexの権限画面では、大きく分けて次の3つを見ます。

  • デフォルトの権限
  • 自動レビュー（Auto-review）
  • フルアクセス

image.png

デフォルトの権限では、Codexがワークスペース内のファイルを読み込み・編集できます。必要に応じて追加のアクセスを要求できます。

自動レビュー（Auto-review）をオンにすると、追加アクセスのリクエストをCodex側の別のレビュアーエージェントがレビューします。ただし、自動レビューは誤る場合があります。

初心者のうちは、フルアクセスはオフのまま始めるのがよいと思います。

フルアクセスをオンにすると、承認なしでコンピューター上のファイル編集や、ネットワークを使うコマンド実行ができるようになります。便利ですが、データの損失、情報漏えい、予期しない動作のリスクが大きくなります。

3. 重要ファイルを先に決める

触ってほしくないファイルは、最初に決めておきます。

たとえば、私はこのあたりを先に守りたいです。

  • .env, .env.local: APIキーや接続情報などの秘密情報が入ることがある
  • データベース migration: テーブル構造やデータ変更に影響する
  • デプロイスクリプト: 本番反映の手順に影響する
  • 本番環境に関係する設定: 公開環境の挙動やセキュリティに影響する
  • 指示していない依存関係: バージョン衝突や脆弱性の原因になることがある

境界がはっきりしているほど、意図しない変更は減ります。

Codexに任せる前に、「ここは触らないで」と書く。これは初心者でもすぐできる安全対策です。

4. タスクは具体的に書く

タスクは、できるだけ具体的に書いた方が安定します。

曖昧な表現:

このコードをいい感じに直して

プロンプトは、以下の形にすると見やすいです。

対象:

目的:

実行:
- 
- 

禁止:
- 
- 

出力:
-

例:

対象: Markdown記事の下書き
目的: 見出しと内容の整理

実行:
- 見出し構成を整理する
- 重複説明を指摘する
- 初心者向け注意点を提案する

禁止:
- 本文生成
- 文体の大幅変更
- 公式未確認の情報を断定しない

出力:
- 修正案のみ

実際の操作では、プロンプトの出し方で何度も失敗しました。

この失敗談にはかなり学びが詰まっているので、今後の記事で集中的に書こうと考えています。

5. 完成後に生成過程と差分を見る

Codexが作業を終えたら、そのまま受け入れない方がよさそうです。

まず見るのはこの4つです。

  • どのファイルを変更したか
  • 変更量が多すぎないか
  • ロジックが合っているか
  • テストや確認が通っているか

初心者ほど「完成しました」という言葉で安心しがちですが、見るべき場所は結果そのものより、差分と確認結果だと思いました。

ちなみに、もしアプリを開発しているなら、Codexがタスクに取り組む過程もぜひ見てみてほしいです。

初心者なりに、開発フローや確認の流れを学ぶ材料にもなるのでおすすめです。

やってみてわかったこと

最初に必要なのは、高度なテクニックよりも作業範囲の整理でした。

Codexに何を任せるか、どこは触らないか、作業後に何を確認するか。この3つを先に決めるだけで、かなり扱いやすくなります。

ただし、Codexの出力は最終結果だけで判断しない方がよいです。

最低限、変更されたファイル、差分、実行ログ、テスト結果を見ます。特に .env、migration、デプロイ関連の変更が含まれていたら、内容を理解できるまでそのまま進めない方が安全です。

おまけ

最近、Codex向けハードウェアの話題も出てきましたね。
私は今、スマホを使ってリモートコーディングをしています。
スマホでCodexを使っている感想、実際に出るエラー、そして専用デバイスとスマホアプリを併用した時にどんな効果がありそうかを整理したいと思います。

次回は、クレジットの節約に関して共有する予定です。
よければ、引き続き見てください。

参考リンク

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?