2026 年 3 月末、Alibaba は alibaba/anolisa を公開しました。これは同社が保守するサーバー向け Linux ディストリビューション Anolis OS を AI Agent 実行基盤として再構築した「Agentic OS」プロジェクトで、正式名称は ANOLISA（Agentic Nexus Operating Layer & Interface System Architecture）です。 本記事では、ANOLISA が解こうとしている問題と、公開されている 4 つのコアコンポーネント（Copilot Shell / Agent Sec Core / AgentSight / OS Skills）の役割、そして開発者が今すぐ触れられる導入手順を整理します。 ANOLISA が目指すもの ANOLISA は Anolis OS の「Agentic 進化版」と位置づけられており、AI Agent ワークロードをサーバー側で安全かつ観測可能な形で動かすためのベストプラクティス実装を狙っています。LLM / Agent がコード編集・シェル実行・ネットワークアクセス・プロセス管理といった OS レベルの操作を当たり前に行う時代において、「アプリケーション境界で守る」従来型セキュリティでは不十分になってきました。ANOLISA はその問題意識を背景に設計されています。 リポジトリ: alibaba/anolisa ホームページ: agentic-os.sh ライセンス: Apache License 2.0 主言語: TypeScript（Copilot Shell）/ Rust（AgentSight）/ C（eBPF プローブ） 公開: 2026 年 3 月 30 日（初版リポジトリ作成） 4 つのコンポーネント ANOLISA は単一のカーネルモジュールではなく、Agent 実行に必要な「シェル・セキュリティ・観測・スキル」を別々のプロダクトとして分離し、RPM で同居運用する構成を取っています。 ...

「もう 2 ヶ月以上、手でコードを書いていない」 Claude Code の生みの親であり、Anthropic でその開発を率いる Boris Cherny がそう語ったのは 2026 年 1 月のことだ。Andrej Karpathy の問いかけに応え、X への投稿でこう明かした。 “For me personally, it has been 100% for two+ months now, I don’t even make small edits by hand.” そして今、そのワークフローが広く注目を集めている。2 日間で 49 の Pull Request を出荷、コードは 100% AI 生成という実績が報告され、X では 30 分間のセッション動画が公開され 300 万回近く再生された。 Boris Cherny とは Boris Cherny は、Claude Code を 2024 年 9 月に社内の個人プロジェクトとして始めた人物だ。当初は自分のコーディングを助けるためのツールだったが、Anthropic 社内でその有効性が認められ、正式なプロダクトへと進化した。 彼は後にこう振り返っている。 “When I created Claude Code as a side project back in September 2024, I had no idea it would grow to what it is today.” ...

Claude Code の Skills を使い込むうちに「あれ、前と挙動が違う……」と感じたことはないだろうか。~/.claude/settings.json に 1 行追記するだけで解決できる。原因は auto-memory だ。 Claude Code の auto-memory が Skills の挙動を変える仕組み Claude Code は会話のたびに学習内容を Memory（~/.claude/projects/.../memory/MEMORY.md）へ自動で書き込む機能（auto-memory）を持っている。 問題はこの Memory の内容が次の会話でコンテキストウィンドウに自動挿入される点だ。これにより、Skills に記述した指示と競合し、設計どおりの挙動から少しずつずれていく。 会話を重ねるほど症状が顕著になるため、原因の特定に時間がかかりやすい。 解決策：autoMemoryEnabled: false ~/.claude/settings.json に 1 行追記するだけで解決する。ファイルが存在しない場合は新規作成し、既存の設定がある場合は {} 内に追記する。 1 2 3 { "autoMemoryEnabled": false } これで Memory への自動書き込み・読み込みが停止し、auto-memory 機能全体が無効化される。 影響範囲 機能 autoMemoryEnabled: false にしたときの変化 Memory への自動書き込み・読み込み 停止 CLAUDE.md の読み込み 変化なし（従来どおり動作） Skills に書いたルールの適用 変化なし（従来どおり動作） CLAUDE.md や Skills の設定はそのまま有効なので、プロジェクト固有のルールが失われる心配はない。 ...

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つしかない。 ...