こんにちは、たけちゃんです。業務でCodex CLIを使用しており、コードや機密情報の流出防止には細心の注意を払っています。https://developers.openai.com/codex/security/#agent-sandboxsandboxモードとは sandboxモードの種類と効果ファイルアクセスに対する制限種類概要ユースケースread-onlyすべてのファイル操作が読み取り専用。編集や生成を伴う指示は一切実行できず、閲覧や調査に限定される。外部破壊リスクを完全に排除したい検証環境や、構成確認のみ行いたい場合。workspace-writeカレントディレクトリと許可されたwritable_roots配下のみ書き込み可。それ以外は読み取りに留め、変更には追加承認が必要。一般的な開発タスク。プロジェクト配下での修正は自由だが、システム領域や別プロジェクトへのアクセスを防ぐ。danger-full-access制限なし。任意パスへの読み書き、ツール実行も可能で、通常のシェルと同等に振る舞う。高度な自動化や統合テストなどサンドボックスが邪魔になる場面。誤操作リスクが最も高いため、CI用途や信頼済み環境のみで利用。ネットワークアクセスに対する制限 Approval Policy・ untrusted: 読み取り以外のほとんどのコマンドが都度承認待ちになる。新しいプラグインやスクリプトの安全性確認で有効。sandboxモードの使い方codexコマンドのオプションとして使うcodex --sandbox <ファイルアクセスのモード> --ask-for-approval <Approval Policy>codex --sandbox read-only --ask-for-approval untrustedとなります。config.tomlに記載する# config.tomlapproval_policy = "untrusted"sandbox_mode = "read-only"# config.toml[sandbox_workspace_write]network_access = true使用例では実際にread-only モードで起動してフォルダの削除を指示した場合どうなるかやってみましょう。codex --sandbox read-onlyho

はじめに：AGENTS.mdが「秘伝のタレ」化していませんか？問題点（人間側）：肥大化したAGENTS.mdは、可読性が悪く、人間がメンテナンスするのが困難（人間側）：AGENTS.mdをチームで共有する場合、巨大なAGENTS.mdファイル全体をレビューしなければならず、差分が分かりにくくなる（AI側）：バックエンド開発者に「フロントエンドのルール」まで読み込ませるのは非効率であり、コンテキストの「ノイズ」となって回答精度を低下させる理想：AIにも「専門分野」を持たせたいClaude Codeのサブエージェント機能です。GitHub Issue #2604）。そこで、Codex CLIの既存機能（カスタムプロンプト）を活用し、この機能を「擬似的に」実装しようと考えました。実装ステップ1：役割（コンテキスト）の物理的な分割プロジェクト内の myproject/.codex/agents/配下に配置します。ディレクトリ構成例：myproject/ <-- プロジェクトルート├── AGENTS.md # 共通ルールファイル├── .codex/│ └── agents/│ ├── backend.md # バックエンドエンジニアの固有ルール│ ├── frontend.md # フロントエンドエンジニアの固有ルール│ ├── designer.md # 設計作成担当の固有ルール│ └── reviewer.md # コードレビュワーの固有ルール└── ...なぜプロジェクト配下なのか？Gitによるチーム共有: これらのAIルールファイルはプロジェクトのソースコードやドキュメントの一部となり、Gitでバージョン管理され、チームメンバー全員に自動で共有されます。コンテキストのローカル性: 特定のプロジェクトに特化したルールを、他のプロジェクトの設定と分離し、独立して管理できます。メンテナンスの容易性: AGENTS.md全体をレビューする必要がなく、変更があった役割ファイル（例: backend.md）だけをレビューすれば済むため、差分が明確になります。myproject/.codex/agents/配下のファイルは以下のような役割ごとのルール（指示）を書きます。myproject/.codex/agents/backend.md の内容例# 役割プロファイル: 熟練のバ

はじめにお久しぶりです。しゅんちゃんです。寒くなってきましたね。Nextat AI活用ブログ記事シリーズとして Serena について書いてみます。TL;DRSerena は LSPを使用してコードを構造的に理解し、LLM/コーディングエージェントに「ファイル全体の読み込み・grep 検索」以外の選択肢を提供する MCP サーバーです。横断的なシンボル探索や依存追跡に強く、タスクによってはコンテキスト使用量の削減が見込めます。LLMのテキスト操作の限界LLM/コーディングエージェントは、コードを単なるテキストファイルとして扱います。結果として...ファイル全体を読み込んだり、grep/置換したりするため、処理時間とコンテキスト使用量が増えやすい宣言と参照の関係を踏まえずに置換するので、誤編集する可能性がある型やシンボルの関係が見えないため、大規模になるほどコードベースの俯瞰が難しくなるここを補うのが Serena の役割です。Serenaの概要何者か：IDE のようにシンボルを抽出してリレーショナルに扱える、セマンティックコード検索・編集ツールを LLM に提供するオープンソースの MCP サーバー仕組み：各言語のLSP（Language Server Protocol）を使用して定義・参照・型情報などを取得して、シンボル単位の操作を可能にしている。対応言語（弊社主要言語のみを抜粋）Go（gopls のインストールが必要）JavaScript / TypeScriptPythonPHP（LSP として Intelephense を使用している。プレミアム機能を使用するには環境変数を設定する必要がある）Markdown（プロジェクト設定を生成するときに明示的に --language markdown を指定する必要がある。ドキュメントの多いプロジェクトで有効）利用先：Claude Code/Desktop、Codex、Gemini-CLI、VSCode/Cursor/IntelliJ、Cline/RooCode、OpenWebUI、Jan、Agno などのクライアントから MCP として利用可能セットアップ（Codex連携）Codex：v0.57.0Serena：v0.1.4uv：v0.8.17uvのインストールhttps://docs.astral.sh/uv/ge

こんにちは、カミオです。検証環境Node.js 23.11.0difit 2.2.3difitとは差分とコメントを組み合わせたAIエージェント用プロンプトを簡単にクリップボードにコピーすることもでき、AIとの連携が念頭に置かれているツールです。https://github.com/yoshiko-pg/difit使い方npx difitREADMEをご確認ください。npx difit . # すべての未コミット差分（ステージングエリア + 未ステージ）npx difit staged # ステージングエリアの差分npx difit working # 未ステージ差分のみレビューするsrc/Application.php:L67255文字にして=====src/Application.php:L73テストを追加して下記レビューの指摘事項を一つずつ修正してsrc/Application.php:L67255文字にして=====src/Application.php:L73テストを追加してnpx difit --cleanおわりにAIエージェントの活用により、コードを書くよりレビューすることの比率が高くなってきていますが、見慣れた画面でレビューできるだけでも気分がだいぶ楽になりますね。AIと連携させずとも、ローカルでGitHubとほぼ同じ画面で差分が確認できるので、Pushの前のセルフレビューとして利用するのもおすすめです。

こんにちは、ヨシムラです。時間をかけたのに成果物がイメージと違う修正を依頼したら、さらに方向がずれてしまうどうも待ち時間が長い割に期待通りにならないと感じることは多いと思います。実はこれは、AI特有の問題ではなく、人にタスクを渡すときにも普通に起こりうる現象です。これはAIも同じです。なぜズレが発生するのかAIに複雑なタスクを投げたとき、出力に時間がかかる完成物の方向性がズレる修正しても修正してもズレが埋まらないという状態は、ほとんどが与えている文脈やスコープが曖昧なことが原因です。AIは、与えられた情報の中から最も“ありえそう”と思われる推論を行います。つまり、ズレは “AIの能力不足” というより、前提条件が合っていないことによる自然な結果として起きています。認識を揃えることで、AIは安定して動くAIが本来持っている性能を発揮させるには、タスクの最初の段階で認識を合わせることが重要です。特に効果が高いのは以下のポイントです。最初にプラン（計画）を出してもらう「まず、このタスクをどう進めるべきかプランを作って」過去の成果物やパターンを参照する「◯◯と同じ構成で作れそう？修正の影響範囲を先に確認する「◯◯を修正した場合、どの部分に影響がある？」自分の認識を言語化して確認する「このタスクは ×× のインターフェイスを実装する方針で考えている。こうした小さな認識合わせは、そのまま依頼者自身の理解のチェックにもなるため、複雑なタスクで特に効果的です。スコープを明確にすると、AIは無駄な推論をしない「このファイルだけを修正してほしい」といった具合に範囲を制限すると、AIが余計な推論にリソースを使わず、結果のブレも減ります。結局、AIの精度は“伝え方”で決まるAIが期待通りの成果物を返せないとき、与えている文脈が足りないだけというケースが多くあります。タスクに入る前に少し時間を使って、背景文脈ゴールスコープを整理して伝えるだけで、AIは安定して、意図通りに動いてくれます。AIは「なんでも自動でやってくれる存在」ではなく、前提が十分に揃ったときに最大のパフォーマンスを出す相棒です。認識合わせのプロセスを自然に取り入れながら、人とAIでより良い成果をつくっていけるチームを目指していきましょう。

皆さんお久しぶりです、かっちゃんです。 最近NextatではCodexを使用して開発の効率を上げていこう期間に入りまして、その一環で記事を書いています。テストケース ✖︎ AI で楽にテストを書こう今回、なぜテストケース ✖︎ AI という組み合わせにしたかというと、自分自身がテストケースを書くのが苦手だからです。笑めっちゃ細かいところまで書かないとダメだし、いろんなパターンのケースを考えないといけないし、思考量も書く量も非常に多くて大変です。そこで文章理解と、思考をまとめるのが得意な AIに嫌な部分を担ってもらおう ということです。大前提として、実装の元となる設計書が詳細に書かれていること。じゃないと今回の記事で紹介する手法の本領は発揮されません。BDDという開発手法を使うBDDとは Behavior-Driven Development（振る舞い駆動開発） の略で、ソフトウェア開発における開発手法の一つです。BDDは、既存のテスト駆動開発（TDD）を発展させたもので、テストを書く前に「何を作るべきか」の共通理解を深めることに重点を置いています。テストを書く前に「何を作るべきか」を深めるというところがポイントです。Gherkin（ガーキン）形式BDDでは「Gherkin（ガーキン）」と呼ばれる特定の形式の自然言語を使用して、テストケースを記述します。Gherkinは以下の3つのキーワードを中心に構成され、これを「シナリオ」または「ユーザーストーリー」と呼びます。キーワード役割意味Given (前提)システムの初期状態や環境を設定する。「〇〇が既に存在する状態のとき」When (事象/行動)ユーザーが行う行動や、システムに起こるイベント。「ユーザーが××という操作をしたとき」Then (結果)期待されるシステムの結果（振る舞い）。「システムは△△という結果を返すはずだ」【記述例】AIに設計を読ませてBDDを書いてもらうまず必要なのがAIに読み込ませるための設計と、BDDを作成してもらうためのルールです。AIへの指示（ルール）ECサイト クーポン適用機能 設計書（要約）今回は例として出しているので簡易的な設計になっています。項目概要機能概要注文時にクーポンコードを入力し、複数のビジネスルールに基づいたバリデーションと割引計算を行い、最終的な注文金額を確定する。処理フロ

はじめにこんにちは、ヨシです。今回は、Kiro に採用されている EARS という仕様の記法について気になったので調べてみました。 Kiro 自体は実務で利用してはいませんが、Kiro で採用されている考え方を理解することで最近流行っている仕様駆動開発の考え方を学べるとも思っています。Kiro とはAWSが開発している Kiro は AI エージェントを使った仕様駆動開発(spec driven development)を行うためのAI IDE (統合開発環境) です。Kiro には大きく2つの概念があります。それが spec と hook です。spec (仕様): アプリケーション開発における機能の開発プロセスを形式化する構造化された成果物hook (フック): イベントに応じて、開発者が見落としがちなことや、作業中にバックグラウンドで完了する定型的作業を自動的に行う機能Kiro はこの2つの概念を利用して、仕様駆動開発を行います。spec の基盤となる3つの主要ファイルKiro の spec によって、プロダクトの要件と技術的な実装詳細とのギャップを埋めることで、開発の反復的作業を削減することができるようになるとのことです。各仕様の基盤となるのは以下の3つの主要ファイルで、Kiro はインタラクティブにこれらを生成します。requirements.md : ユーザーストーリーと受け入れ基準を構造化されたEARS表記法で記述design.md : 技術アーキテクチャ、シーケンス図、実装上の考慮事項などtasks.md : 個別かつ追跡可能なタスクを含む詳細な実装計画例えば、プロジェクトで foo という機能を開発する際には以下のように spec として3つのファイルを後述のワークフローで段階的に定義し、これらのドキュメントを元にAIエージェントによる仕様駆動開発が行われます。ワークフロー具体的な開発のワークフローは、以下のような開発フェーズを段階的に行っていくというものになります。 これによって、次のステップに進む前に各ステップが適切に完了することを保証できるようになっています。要件フェーズ (Requirements Phase) requirements.md ファイルを作成/編集デザインフェーズ (Design Phase) design.md ファイルを

はじめにお久しぶりです。ヨシです。AI活用ブログ記事シリーズの第三弾です。昨今、Codexなどの生成AIのCLIツールを利用した並列開発が流行っていますが、今回は並列開発に向けた準備として行っていることについて語りたいと思います。本格的な並列開発についてはとある事情からまだ行えていませんが、その準備として何をやっているかについて解説します。また、そのような流れからCLIやターミナル周りの仕組みを強化するモチベーションが湧いており、今回の記事では、私が行っているCodexを活用したプロジェクトのドキュメント運用についてまとめ、ディレクトリの分割思想やターミナルマルチプレクサ／lazygitとの連携などについても解説します。プロジェクトディレクトリの全体構造まず、プロジェクト全体のディレクトリ構造について語りたいと思います。現在私がアサインされているプロジェクトでは複数のリポジトリが存在しており、それらをまとめて一つのディレクトリに配置することにしています。以下のように、ルート直下に各リポジトリを包むラッパーディレクトリを配置し、その中ではgit worktreeで並列展開できるようにしています。.├── AGENTS.md # プロジェクト全体についてのAGENTS.md├── docs # ドキュメント専用リポジトリ├── proj-1-repos # 配下に同一のリポジトリのworktree展開 │ ├── proj-1-main│ ├── proj-1-sub│ └── proj-1-third├── proj-2-repos└── proj-3-reposこのような配置では以下のような目的のもとで運用を行っています。人間とCodexが同時に作業しても衝突しづらいよう、*-repos 配下に *-main と *-sub などを用意して必要分だけworktreeを増設できますルートから横並びの構造にしているため、tmuxやZellijでタブを切り替えるだけで関連リポジトリへ即アクセスできますそれでは、このディレクトリの運用についていくつかの観点で詳しく解説していきたいと思います。Codex生成ドキュメントの管理まず、Codexを使う上では特にドキュメントを多く生成させるようにしています。ソースコードの変更後に何をどのような目的で修正したかや、既存のコードベースの

こんにちは、ナカエです。 前回の NextatでのAI活用状況 に引き続き、AI活用ブログ記事シリーズの第二弾です。MCP公式でも、認可の仕様の議論が行われています。参考： Authorization - Model Context Protocol本記事では、Codexの設定ファイル（~/.codex/config.toml）でMCPの認可を設定する方法を見ていきます。※ 以下はCodex CLI 0.50.0で検証した内容になります。Codex CLIのMCPの認可設定例1. ローカルMCPサーバー（認可なし）Serena を使う場合の設定が下記です。 Serenaは uv を使ってローカルで起動するのが一般的です。起動に時間がかかることがあるので、起動時のタイムアウトを設定しています。[mcp_servers.serena]command = "uvx"args = [ "--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex",]startup_timeout_sec = 302. リモートMCPサーバー（アクセストークンによる認可）2-1. プロキシー利用Codex 0.46.0より前のバージョンではCodexのMCPサーバー接続のトランスポートは標準入出力しかサポートされていなかったため、mcp-proxy などの標準入出力のトランスポートをHTTP+SSE（現在非推奨）やStreamable HTTPに変換してくれるプロキシーを利用する必要がありました。HTTPのAuthorizationヘッダーにGitHubのPersonal Access Token（以下PAT）をBearerトークンとして設定することで認可を行います。コーディングエージェントがMCPを使って読み書きする権限はPATの発行時に設定することになります。[mcp_servers.github]command = "mcp-proxy"args = [ "--transport", "streamablehttp", "-H", "Authorization", "Bearer {GitHubのPAT}", "https://api.githubc

1. はじめにこんにちは、Hです。2. NextatのAI活用状況Nextatでは業務内容に応じて最適なAIを使い分けています。(1) Gemini利用展開施策：GoogleのAIサービス「Gemini」の利用を展開しています目的：情報収集、文章作成、アイデア発想、簡単なデータ分析など、日常的な業務における生産性向上を目指します(2) 開発特化型AIの活用施策：一部のプロジェクトで、開発業務に特化したAIツールを導入しています具体的なツール：Codex CLI​：コマンドラインインターフェース（CLI）ベースでの開発作業の効率化GitHub Copilot：コードの自動補完や提案機能により、コーディング時間を短縮3. AIツールの選定基準Gemini for Google Workspaceの採用:Google Workspace版のGeminiは、利用データがAIの学習に利用されないことが保証されています。これにより、機密情報が外部に漏れたり、学習データとして再利用されたりするリスクを軽減しています開発特化型AIの制限:プロジェクトごとにGitHub CopilotやCodex CLIが利用できるか判断開発特化型AIツールにおいても、社内コードが第三者に流出しないよう、利用設定やアクセス権限を厳格に管理4. 勉強会の実施Nextatでは、AIを最大限に活用するための勉強会も同時に行っています。実施内容： 週に一度、AI社内勉強会を開催目的：ナレッジの非属人化: 各社員が見つけたAIの「良い使い方」「効果的なプロンプトの設計手法」「業務効率が劇的に上がった具体的な事例」といったグッドプラクティスの共有リテラシーの平準化: 組織全体でAIリテラシーを高め、活用レベルの底上げ応用力の強化: 共有された事例を参考に、社員一人ひとりが自身の業務への応用を考え、実践するサイクルを生む5. 今後のAI活用予定今後もより高い効果を目指し、新しいAIツールの検証および研究を継続的に行っています。他AIツールの実験的導入と比較: コーディング能力に強みを持つAnthropic社の「Claude Code」を実験的に導入予定 新しい開発手法の研究: 今までのやり方にとらわれず、要件定義・設計からテストケース作成までよりAIを有効活用できる開発手法の研究6. まとめNextatは、AIを