Qiita に投稿された「Claude Code を Level 5 まで育てたら、開発が「指示と確認だけ」になった — 実ファイル構成で解説」が大きな反響を呼んでいる。CLAUDE.md・Skills・Hooks・Agents を組み合わせて Claude Code を 5 段階で「育てる」ことで、人間の作業を「指示と確認だけ」に絞り込むアプローチを実ファイル構成とともに解説した記事だ。 「AI にコードを書かせている」と「AI と開発している」は違う Claude Code を導入した当初は、毎回こんなプロンプトを書いていたという： 1 2 3 4 5 UIテキストはハードコーディングしないでください。 src/i18n/ja.ts に追加してから使ってください。 テストも書いてください。 外部リンクには rel="noopener noreferrer" を付けてください。 コミット前に npx astro check と npm test を実行してください。 毎回同じことを書くのは「AI にコードを書かせている」状態であり、「AI と開発している」とは言えない。同氏は 1 か月の試行錯誤を経て、作業は「何を作るか指示する」と「動作確認する」だけになったという。 Claude Code 5 つのレベルの全体像 Level 追加要素 何が自動化されるか 人間がやること 1 素のプロンプト なし 全指示を毎回手打ち 2 + CLAUDE.md プロジェクトルールの自動読み込み ルール違反の指摘が不要に 3 + Skills 手順書のオンデマンド注入 定型作業の手順説明が不要に 4 + Hooks 品質チェックの自動実行 「テスト実行して」が不要に 5 + Agents 並行レビューの自動実行 レビュー依頼が不要に Level 2: CLAUDE.md — 「プロジェクトの憲法」を持たせる プロジェクトルートに CLAUDE.md を置くと、Claude Code が会話開始時に自動で読み込む。これは「プロジェクトの憲法」だ。 ...

.env よ、安らかに眠れ——。 AI 時代の開発現場では、シークレット（API キー・データベースパスワード・証明書など）の扱い方が大きな課題になっています。従来は .env ファイルに書いておけばなんとかなっていました。しかしチーム規模が拡大したり、AI エージェントが複数のサービスを横断して動くようになると、.env ベースの管理はほころびを見せてきます。 Infisical は、そんな .env の時代を終わらせるべく登場したオープンソースのシークレット管理プラットフォームです。 .env の何が問題なのか .env ファイルによるシークレット管理には以下のような問題があります。 ディスクに残る: 誤って git add .env してしまうリスクが常に存在する 同期が難しい: 複数人・複数環境での値の一元管理が困難 ローテーションが手動: シークレットを更新するたびに全メンバーへの周知が必要 監査ログがない: いつ誰がどの値を変更したか追跡できない AI エージェントとの相性が悪い: エージェントが環境変数ファイルを読み書きすると漏洩リスクが増大する Infisical とは Infisical は、シークレット・証明書・特権アクセスを一元管理するオープンソースプラットフォームです。2026年4月時点で GitHub 26,000 スター超を獲得しており、Vault の OSS 代替として注目されています。 最大の特徴は、シークレットをランタイム時に取得する設計にあります。.env ファイルのようにディスクに値を保存しないため、ファイルベースの漏洩リスクを根本から排除します。 主な機能 シークレット管理 プロジェクト・環境（dev / staging / prod）ごとのシークレット管理 シークレットのバージョン履歴と自動ローテーション 変更の監査ログ シークレット参照（他のシークレットの値を参照する変数展開） 証明書管理（PKI） プライベート CA の構築と証明書の発行 ACME プロトコル対応で Let’s Encrypt 互換のワークフロー 証明書の有効期限監視と自動更新 統合機能 CLI: あらゆる言語・フレームワークのコマンドをシークレット付きで実行 SDK: Node.js、Python、Go、Java など主要言語のネイティブ SDK インフラ統合: Kubernetes、GitHub Actions、AWS、GCP、Azure など 基本的な使い方 インストール 1 2 3 4 5 # macOS (Homebrew) brew install infisical/get-cli/infisical # npm npm install -g @infisical/cli ログインとプロジェクト初期化 1 2 3 4 5 # Infisical にログイン infisical login # プロジェクトに紐付け infisical init シークレットを注入してコマンドを実行 1 2 3 4 5 # .env の代わりに Infisical からシークレットを取得してアプリを起動 infisical run -- node app.js # 環境を指定 infisical run --env=staging -- python manage.py runserver SDK から直接取得（Node.js の例） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import { InfisicalSDK } from "@infisical/sdk"; const client = new InfisicalSDK(); await client.auth().universalAuth.login({ clientId: process.env.INFISICAL_CLIENT_ID, clientSecret: process.env.INFISICAL_CLIENT_SECRET, }); const secret = await client.secrets().getSecret({ secretName: "DATABASE_URL", projectId: "my-project-id", environment: "production", }); AI 時代のシークレット管理 AI エージェントや MCP サーバーが普及した今、シークレット管理の重要性はさらに高まっています。 ...

株式投資の取引スタイルは、ポジションを保有する時間軸によって「スキャルピング」「デイトレード」「スイングトレード」「中長期投資」の 4 つに大別される。本稿では、松井証券の解説ページを参考に、それぞれの特徴とメリット・デメリットを整理する。 デイトレードとは デイトレードは、保有するポジションを 当日中に反対売買 するトレードスタイル。1 日の間に何度も取引を行うことが多く、1 回のポジション保有時間は数十分から数時間とさまざまだが、ポジションを翌日に持ち越さない のが大きな特徴。 同じく当日中に売買を完結させる手法に「スキャルピング」がある。スキャルピングはポジション保有時間が 数秒〜数分 とさらに短く、1 日に数十回のトレードを重ねる。 スイングトレードとは スイングトレードは、ポジションを 数日〜数週間 にわたって保有する取引手法。デイトレードのような短期売買では相場状況の予測が難しくなるため、スイングトレードでは長めの時間軸で「トレンド」（相場の方向性や値動きの傾向）を分析する。 基本戦略は、上昇トレンド時に「買い」、下降トレンド時に「売り」を行う 順張り で利益を狙うこと。 4 つのスタイルの比較 スタイル 保有期間 1 日の取引回数 スキャルピング 数秒〜数分 多い デイトレード 数分〜数時間 数回〜数十回 スイングトレード 数日〜数週間 少ない 中長期投資 数ヶ月〜1 年以上 少ない スキャルピングやデイトレードは、相場状況に合わせて柔軟に売買できるため、うまくいけば損失を抑えつつ利益を積み上げられる。一方、発注タイミングを瞬時に判断する必要があり、誤ると損失が続くこともあるため 上級者向け。初心者は少額・1 日数回程度の売買から始めるのが無難。 スイングトレードは保有期間が長く取引回数も少なめで、トレンドを意識するため日中の小さな値動きはあまり気にする必要がない。チャートからトレンドを的確に予測できれば大きな利幅も狙えるが、翌日まで持ち越すため取引時間外のニュースや海外（特にアメリカ）相場の影響を受ける リスクがある。 中長期投資は数ヶ月〜年単位でポジションを保有するスタイル。直近の値動きやトレンドではなく、現時点の株価が企業価値・業績・将来性に対して割安か という観点が重要になる。 各スタイルのメリット・デメリット デイトレードのメリット・デメリット メリット 資金効率がよい — 1 日に何度も取引するため、利益をすぐ次の取引に回せる。元手が少なくても短期間で資金を増やせる可能性がある。松井証券の「一日信用取引」では、デイトレード対象の手数料・金利・貸株料が約定代金にかかわらず 0 円のため、信用取引でレバレッジをかけることでさらに資金効率を高められる。 1 回あたりのリスクが小さい — その日のうちに反対売買するため、原則として損失は最大でも 1 日で動く値幅の範囲内。取引数量を抑えればさらにリスクを縮小できる。 持ち越しリスクがない — 夜間にアメリカ株式市場が暴落しても、ポジションを持っていなければ影響を受けない。精神的な負担が小さい のも利点。 デメリット 一度に大きな利益は期待できない。 細かな利益を積み重ねるには取引回数を増やす必要があり、取引時間中は値動きを細かくチェックする必要がある（取引に集中できる時間の確保が前提）。 スイングトレードのメリット・デメリット メリット ...

東京大学の院生（shunya_sudo）が、45 本の cron ジョブ・36 個のカスタムエージェント・132 本の Python スクリプト で構成した日常業務自動化システムの全記録を Zenn で公開した。M1 冬から約半年間 Claude Code を使い続けて構築したシステムで、メール処理・論文監視・ML コード開発・システム自己監視まで設計原則と実装を網羅している。 システムの全体構成 macOS 上で以下の構成で稼働している。 構成要素 数 cron ジョブ 45 個 カスタムエージェント 36 個 Python スクリプト 132 本 基本アーキテクチャは 「Python が処理、Claude CLI が判断」 というシンプルな分離原則に基づく。データ取得・加工は Python スクリプトが担い、要約・判断・生成を Claude CLI が受け持ち、定時実行は cron で管理する。 主な自動化タスク メール処理（Gmail API） Gmail API を用いてメールを 4 段階に自動分類 し、返信が必要なものには 下書きを自動生成 する。 緊急対応 / 要確認 / 参照 / アーカイブの 4 レベル分類 Claude が文脈を読んで返信の下書きを生成 最終判断・送信は人間が行う 日程調整（ICS URL） ICS URL を活用してカレンダーを自動更新し、日程調整の候補時間を自動挿入する。手動でのカレンダー確認作業をゼロにした。 ...

django-mptt の README を開くと、いきなり以下の文言が目に飛び込んでくる。 This project is currently unmaintained You can find alternatives to django-mptt on Django Packages. Maybe you do not need MPTT, especially when using newer databases. See django-tree-queries for an implementation using recursive Common Table Expressions (CTE). 「単に飽きて投げ出した」のか、それとも「技術的に役目を終えた」のか。本稿では django-mptt のリポジトリ、CHANGELOG、ソースコードを実際に読んで、その背景と後継への移行可否を整理する。 1. 経緯 — メンテナンス側の事情 CHANGELOG.rst を時系列で追うと、放棄宣言とその後の経緯が見て取れる。 v0.13: 公式に「unmaintained」を宣言 0.13 ==== - **MARKED THE PROJECT AS UNMAINTAINED, WHICH IT STILL IS** - Reformatted everything using black, isort etc. - Switched from Travis CI to GitHub actions. ... この時点で「もうメンテしません」と公式宣言がなされた。 ...

NTTデータの茂呂 範さんが Zenn に投稿した記事「設計書・コード・テストを全部AIに書かせて半年間開発してみたよ」が大きな反響を呼んでいる。2025年10月から2026年3月の6ヶ月間、設計書・ソースコード・テストケースの一切を AI に生成させ、社員はレビューのみに徹したという取り組みだ。 プロジェクト概要 期間: 2025年10月〜2026年3月（約6ヶ月） 対象: 商用システムのサブシステム（グリーンフィールド開発） アーキテクチャ: TERASOLUNA（NTTデータ標準）+ AWS 利用 AI: GitHub Copilot 体制: 社員3名（開発担当 + 経験豊富なメンター社員で構成） 社員は設計書・ソースコード・テストケースを1行も手で書かなかった、というのが最大の特徴だ。 AI ネイティブ開発の実態 ファイル構成と規模 .github ディレクトリだけで133ファイル、約9,000行（空行除く）のコードが生成された。プロンプト定義やワークフロー設定も含め、インフラ構成に至るまで AI が出力したものをレビュー・採用している。 コンテキスト管理の工夫 LLM のコンテキストウィンドウ制約に対処するため、以下の設計方針を採用した。 個別ファイルをできるだけ小さく保つ ファイル間参照を最小化し、コンテキストの柔軟性を維持する INPUT/OUTPUT 仕様書へのシフト 従来の詳細設計書は「処理フロー」を細かく記述するものだった。今回は発想を転換し、INPUT/OUTPUT 仕様のみを AI に渡す アプローチを採った。ロジックの実装は AI に委ねることで、設計書の記述コストを大幅に削減している。 反響：大手 vs. 個人開発者 このアプローチに対し、個人開発者の @HAL1986____ 氏は X (Twitter) で次のようにコメントした。 さすがNTTデータ、という感じ。 正直、このレベルを本気でやられてしまうと、純粋な開発力では全く太刀打ちできないのよな。 僕らは大手に出来ない戦い方をしないとダメだな。 組織として標準アーキテクチャ・標準ツール・大規模なレビュー体制を揃えた上で AI を活用する大企業と、個人や小規模チームが同じ土俵で戦うことの難しさを端的に表している。 大手企業が AI をエンタープライズの開発プロセスに正式に組み込み始めた今、スモールチームが取るべき戦略は「大手が苦手な領域」への集中と差別化かもしれない。 まとめ NTTデータの事例は、AI 駆動開発が「実験」ではなく「本番商用システム」レベルに到達したことを示す重要なマイルストーンだ。 設計書の書き方を INPUT/OUTPUT 仕様書にシフト コード・テストの生成を AI に全面委任 社員はレビュー・品質担保に集中 この流れは今後さらに加速するだろう。開発者が問われるのは「コードを書く力」より「AI の出力を正しく評価・修正できる力」になりつつある。 ...

CreaoAI が25名で6週間のリリースサイクルを1日に短縮した事例では、PR 管理ツールとして Graphite が採用されていた。1日8回デプロイ・AI が大量に PR を量産する運用で、素の GitHub PR フローは何が詰まり、Graphite は何を解決するのか。本記事では Graphite の3本柱（スタックドPR・マージキュー・AIレビュー）を、CLI コマンドと具体的な運用シナリオで解説する。 Graphite とは Graphite は GitHub 上の PR ワークフローを拡張する開発者プラットフォーム。2025年3月に Anthropic から $52M の Series B を調達し、同時に AI コードレビュー「Diamond」をローンチした（現在は Graphite Agent に名称統合）。元 Airbnb・Meta のエンジニア出身チームが、Meta 内部で使われていた Phabricator / Sapling 的なスタック開発体験を GitHub に持ち込んだのが出発点だ。 主要機能は3つに整理できる。 スタックドPR — 大きな変更を依存関係のある小さな PR の連鎖に分割する マージキュー — スタックを理解した状態で main にマージを直列化する（stack-aware） Graphite Agent（旧 Diamond）+ Chat — AI によるコードレビューと対話的修正 スタックドPR：大きな差分を「小さなレビュー単位の連鎖」に分解する 何が問題だったのか AI エージェントや生産性の高い開発者は、1つのフィーチャーを実装する過程でしばしば以下のような複数階層の変更を生む。 DBスキーマの追加 それを使う API エンドポイント 認証ミドルウェアの更新 フロントエンドの呼び出し 従来の GitHub PR モデルだと選択肢は2つしかない。 ...

文京区が4月10日に発行した区報ぶんきょう No.1881（令和8年4月10日号）は、新条例施行・制度改定・AI 活用サービス開始など区民生活に直接影響するトピックが多数盛り込まれた重要号でした。本記事では全8ページの内容を要約し、特に注目すべき項目を指摘します。 トップ記事: こどもの権利条例が4月1日に施行 「文京区こどもの権利に関する条例」が2026年4月1日に施行されました。条例で明記された権利は4分類です。 安心して生きる、過ごすための権利: 命が守られ、尊重されること、安全・安心に過ごせること 必要な支援を受け、守られる権利: 人種・国籍・性別・性的指向・性自認・意見・障害・経済状況等を理由としたあらゆる差別や虐待・いじめを受けずに安心して生きていけること 成長と可能性に関する権利: 遊び・学び・休むこと、繰り返し挑戦できること、個性が認められ可能性が大切にされること 意見等の表明と仲間づくりに関する権利: 自分の意見・考え・気持ち等を表明でき、それが尊重されること 大人へのお願いとして「こどもに関することが決められ・行われるときは、そのこどもにとって最も善いことは何かを第一に考える」「こどもの意見を受け入れることが難しい場合でも、なぜ難しいかを十分に説明する」と明記されています。 問合せ: こども若者政策課 こどもの権利係 ☎03-5803-3129 注目: 生成AI「文京ごみナビ」運用開始 区のごみ分別案内サービスに生成 AI を搭載してバージョンアップしました。24時間365日 AI が自動応答し、多言語対応・画像検索が可能になりました。 LINE 版: LINE アプリから「文京区資源環境部リサイクル清掃課」を検索、または二次元コードで友だち追加 ブラウザ版: 区 HP から「文京ごみナビ」と検索 3/31 以前に LINE で友だち登録済みの場合は追加手続不要。ブラウザ版では画像検索などの一部機能が制限されます。 問合せ: リサイクル清掃課 ☎03-5803-1135 補足: LINE アプリのインストール手順 LINE 版「文京ごみナビ」を利用するには、まず LINE アプリ本体のインストールが必要です。LINE 公式のインストールガイドに基づく手順は以下のとおりです（2024年3月29日更新版）。 iPhone の場合 スマートフォンのブラウザから LINE 公式サイト にアクセスし、[ダウンロード] をタップ App Store の LINE アプリページに移ったら [入手] をタップ App Store 上で [開く] と表示されればインストール完了 Android の場合 スマートフォンのブラウザから LINE 公式サイト にアクセスし、[ダウンロード] をタップ Google Play ストアの LINE アプリページに移ったら [インストール] をタップ Google Play ストア上で [開く] と表示されればインストール完了 インストールが完了すると、スマートフォンのホーム画面に LINE アイコンが表示されます。初回起動後は電話番号認証等の初期設定を済ませると、トーク・通話・公式アカウントの友だち追加などが利用可能になります。 ...

MetaのGenAIチーム（LLaMA）出身のCo-FounderであるPeter Pang（@intuitiveml）が率いるエージェントプラットフォーム企業CreaoAI（25名）が、「AIファースト」を本気で実践した結果、コードの99%をAIが書き、かつてのリリースサイクル6週間を1日に短縮した方法を解説している。 元記事タイトルは “Why Your ‘AI-First’ Strategy Is Probably Wrong”。@SuguruKun_ai がX（旧Twitter）のスレッドで日本語解説している。 AIを「導入した」会社と「前提に組み直した」会社の違い 多くの企業は既存のプロセスにAIを乗せています。エンジニアがCursorを開き、PMがChatGPTで仕様書を書く――ワークフローは変わらず、効率が10〜20%上がるだけです。 AIファーストとはまったく別物です。AIファーストとは、「AIがメインのビルダーである」という前提でプロセス・アーキテクチャ・組織を再設計することです。「どうすればAIがエンジニアの役に立てるか？」ではなく、「どう再構築すればAIがビルドし、エンジニアが方向と判断を提供できるか？」という問いです。 ハーネスエンジニアリングとは何か OpenAIが2026年2月に発表した概念で、CreaoAIが実践の中で独自に到達していたアプローチと一致しました。 エンジニアリングチームの主な仕事はもはやコードを書くことではなく、エージェントが有用な作業を行える「環境（ハーネス）」を整えることである。 失敗が起きたとき、解決策は「もっと頑張れ」ではなく「どのケイパビリティが欠けているか、エージェントにとって読み解けるようにするにはどうすればよいか」を問うことです。 3つのボトルネックを解消した CreaoAIはAI移行前に3つの深刻な問題を抱えていました。 ① プロダクトマネジメントのボトルネック エージェントは2時間でフィーチャーを実装できます。数週間の計画サイクルがボトルネックになります。仕様書レビューではなく、プロトタイプ→リリース→テスト→反復のループで動く必要があります。 ② QAのボトルネック ビルド時間2時間・テスト時間3日では話になりません。AIが書いたコードをAIが構築したテストプラットフォームで検証し、バリデーションを実装と同速度で動かします。 ③ ヘッドカウントのボトルネック 競合は100倍の人員。CreaoAIは25名。採用では追いつけないため、設計で追いつく必要がありました。 アーキテクチャ統合：モノレポへ移行した理由 複数リポジトリにまたがる変更はAIエージェントにとって「不透明」でした。AIは全体像を把握できず、クロスサービスの影響を推論できません。 モノレポへ統合した一番の理由：AIがすべてを見られるようにするため。 ハーネスエンジニアリングの原則では「エージェントが検査・検証・変更できる形にコードを引き込むほどレバレッジが増す」とされる。1週間かけて新設計を策定し、さらに1週間でエージェントを使ってコードベース全体をリアーキテクチャした。 技術スタック詳細 インフラ：AWS 自動スケーリングのコンテナサービスとサーキットブレーカーロールバックで運用。デプロイ後にメトリクスが劣化すると自動でリバートします。CloudWatchを中枢神経系として使い、25以上のアラームとカスタムメトリクスで全サービスから構造化ログを収集します。 CI/CD：GitHub Actions（6フェーズ） 1 Verify CI → Build/Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release CIゲートは型チェック・リント・ユニットテスト・統合テスト・Dockerビルド・Playwright E2Eテスト・環境パリティチェックをすべて必須で実施。手動オーバーライドは存在しない。パイプラインが決定論的であるため、エージェントが結果を予測して障害を推論できる。 AIコードレビュー：Claude Opus 4.6 PRのたびに3つのClaudeレビューパスを並列実行します。 コード品質 — ロジックエラー、パフォーマンス問題、保守性 セキュリティ — 脆弱性スキャン、認証境界チェック、インジェクションリスク 依存関係スキャン — サプライチェーンリスク、バージョン競合、ライセンス問題 1日8回デプロイする状況で人間レビュアーがすべてのPRに集中し続けることは不可能だ。これはサジェスチョンではなくレビューゲートである。 ...

フロントエンドエキスパートの mizchi さんが「チームでの skills 共有に apm いいじゃん。採用」と X にポストして話題になった APM（Agent Package Manager）。Microsoft がオープンソースで開発しているこのツールは、AI エージェントの設定を package.json のように宣言的に管理・共有できます。 APM とは APM は AI エージェント向けの依存関係マネージャーです。npm や pip がライブラリ依存を管理するように、APM はエージェントが必要とするコンテキスト（スキル、プロンプト、プラグイン、MCP サーバーなど）を apm.yml に宣言して管理します。 対応エージェント: GitHub Copilot Claude Code Cursor OpenCode Codex CLI 解決する問題 AI コーディングエージェントを使うには、標準設定・プロンプト・スキル・プラグインといったコンテキストが必要ですが、現状は開発者が各自で手動セットアップしています。移植性がなく、再現性もありません。 APM を使えば、プロジェクトに apm.yml を 1 つ置くだけで、リポジトリをクローンした全員が同じエージェント環境を即座に再現できます。 基本的な使い方 インストール 1 2 3 4 5 6 7 8 # macOS / Linux curl -sSL https://aka.ms/apm-unix | sh # Homebrew brew install microsoft/apm/apm # pip pip install apm-cli apm.yml の設定例 1 2 3 4 5 6 7 8 9 10 11 12 name: your-project version: 1.0.0 dependencies: apm: # 任意のリポジトリからスキルを取得 - anthropics/skills/skills/frontend-design # プラグイン - github/awesome-copilot/plugins/context-engineering # エージェントプリミティブ - github/awesome-copilot/agents/api-architect.agent.md # バージョン指定した APM パッケージ - microsoft/apm-sample-package#v1.0.0 セットアップ 1 2 3 git clone <org/repo> cd <repo> apm install # エージェント設定が一括セットアップされる マーケットプレイスからのインストール 1 2 apm marketplace add github/awesome-copilot apm install azure-cloud-development@awesome-copilot 主な機能 1 つのマニフェストで全対応 apm.yml で以下をすべて管理できます: ...