TL;DR CLAUDE.mdはSystem Promptではなく、User Messageとして注入される セッション後半になると影響力が薄れるため、セッションを通して守らせたいルールの置き場所には向かない CLAUDE.mdにはセッション開始時の作業を助ける情報だけを書き、ルールは .claude/rules/ に置く はじめに Claude Codeを使っている人なら、CLAUDE.mdに何を書くかで一度は悩んだことがあるのではないでしょうか。 コーディングルール、命名規則、テストの方針、コミットメッセージのフォーマット。色々なことを書いている人が多いと思います。自分もそうでした。 ただ、CLAUDE.mdの内部的な扱われ方を知ると、そこに書くべきものの考え方が結構変わります。結論から言うと、CLAUDE.mdにはセッション開始時の作業を助ける情報だけを書いて、ルールは .claud
CLAUDE.md は、Claude Code の性能を最大限に引き出すための最も重要な設定ファイルです。しかし、「とりあえず全部書いておけばよい」というものではありません。本記事では、内部メカニズムを踏まえた効果的な書き方を解説します。 CLAUDE.mdとは何か CLAUDE.md は、プロジェクトルートに配置する Markdown ファイルです。Claude Code はセッション開始時にこのファイルを自動的に読み込み、記述された内容を会話のコンテキストに含めます。LLM はセッション間の記憶を持たないため、CLAUDE.md にコーディング規約やビルドコマンドを記述しておくことで、毎回「プロジェクトを理解した状態」から作業を開始できます。 CLAUDE.mdの内部メカニズム 「短く書くべき」「普遍的な内容だけを書くべき」と言われる理由は、技術的な制約によるものです。 コンテキストウ
筆者の実体験をもとに Claude Code を活用して整理しました。公式ドキュメントと挙動が異なる場合は公式を優先してください。 2026-02-11 更新: @karaage0703 さんに教えていただき、Claude Code v2.1.3 で Slash Commands が Skills に統合された件を反映しました。YAML frontmatter のフィールド一覧も公式ドキュメント準拠に更新しています。 Claude Code の拡張機能（Slash Commands, Skills, Agents, Plugins）の違いがわかりにくかったので、実際に触りながら整理したメモです。 拡張機能の全体像 Plugin（配布パッケージ） ├── Skills（コマンドの上位互換） ├── Agents（カスタムエージェント） ├── Hooks（ライフサイクルフック） └── MC
Agent Teamsは2026年2月5日にOpus 4.6と同時リリースされた実験的機能で、Claude CodeのSubagentsを独立プロセス化し、双方向にメッセージングできるようにする仕組みです。 Orchestrate teams of Claude Code sessions - Claude Code DocsCoordinate multiple Claude Code instances working together as a team, with shared tasks, inter-agent messaging, and centralized management.Claude Code Docs一言でいうとSubagentsを拡張してステートフルにした機能です。各エージェントが自分のインボックス（~/.claude/teams/配下のJSONファイル）を
「AIにコードを書かせたい」 「面倒な作業を自動化したい」 と思ったことはありませんか？ プログラミング経験がなくても、自然な日本語でAIに指示するだけでアプリやWebサイトが作れる時代が到来しています。その中心にいるのが「Claude Code」です。 2025年2月にベータ版としてリリースされ、わずか1年足らずで176回以上のアップデートを重ね、今や開発者にとって欠かせないツールへと成長しました。2026年現在、v2.0系へと進化を遂げ、IDE連携やMCPサーバー機能、Agent Skillsなど、より実用的な機能が次々と追加されています。 この記事では、Claude Codeの基本から創業者Boris Cherny氏直伝のテクニック、実践的なワークフロー、最新のAgent Skills活用法まで、初心者の方にもわかりやすく解説していきます。 1. Claude Codeとは？Chat
今ならClaude 4.5 Opusに匹敵し高速に動作するという「Kimi K2.5」が利用可能です。こちらはGithub Copilot不要となります。 Git Worktree (gtr) 便利（割愛） OpenCodeの実行 それでは、ぽちぽち試してみましょう。SamuraiAIのサービスサイト(Next.js)のレポジトリを使っています。 /init AGENTS.mdが生成されます。とりあえず実行しておきましょう。AI用のレポジトリ仕様書になります。cluadeの形式も利用できます：https://opencode.ai/docs/rules/ ctrl+p & New session 先程initで使ったセッションが邪魔だと思ったので、新しくセッションを切りコーディングを開始します。 Buildモード コード生成させます。こないだISMSの更新審査対応が完了して、新しい認証ロゴ
はじめに こんにちは。カイポケコネクトの開発推進チームでエンジニアをしている @_kimuson です。 開発推進チームではエンジニアの生産性向上をミッションに掲げているため、最近では積極的にAI活用を推進しています。 上記エントリでは、タスクごとの協業レベルを定義しより低い協業レベル（＝できるだけLLMに移譲しきる）を実現するための方針を紹介しました。 このエントリではより具体的に、Claude Codeをフル活用してこういったワークフローの設計を組織に適用する際の知見をまとめてみようと思います。 設計するワークフローの協業レベルを意識する 前回のエントリでは、ワークフローを設計するに当たって協業レベル、つまりどの程度LLMに権限移譲するか、をデリゲーションポーカーの分類を借りて整理しました。 よくあるLLMの利活用シーンと対応する移譲レベルは下記のように対応します： 流れ 協業レベル
本記事では、エンジニアがつくってきた“自分仕様のAIツール”やAI活用術をご紹介します。エージェントやBot、LLM連携ツールなど、実用的なものから、ちょっと遊び心のあるものまで。プロンプト設計やUIの工夫、うまくいかなかったことや思いがけない発見を通して、AIとの付き合い方をのぞいていきます。AIをどう使うかだけでなく、どんな距離感で付き合っているのか。誰かのAIとの向き合い方が、あなたとAIのちょうどいい“さじ加減”の手がかりに。 Ubieの鹿野です。普段はUbieでプロダクトエンジニアとして働いていて、フロントエンド・バックエンド・モバイルアプリ開発等をしています。2025年5月頃から「Claude Codeにタスク丸投げおじさん」を自称しています。 Claude Codeを始めとするAIエージェントの登場で、コードが生産されるスピードと量は劇的に向上しました。しかし、実際の開発では
3. アップデート履歴 次にskills登場後からskillsに関連する主要な（skillsの立場が変化するような）アップデートを見てみます。 細かいUXの改善系のアップデートは多数含まれているのですが、ここでは省略しています。 v2.0.20: Skills登場 リリース✨ v2.0.43: subagentsのskillsフロントマターの追加 subagentsのフロントマターでskillsフィールドを指定できるようになりました。 これによりスタートアップ時にsubagentsに特定のskillsを読み込むことができるようになりました。 v2.1.0: context: fork、agentフィールド このアップデートでskillsに多数の機能が追加されました。 skillsにcontext: forkフロントマターの追加 skillsのフロントマターで context: fork を
AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code（IaC）を導入したものの、IaC化した恩恵が思っていたより少なく、IaCで基盤を統一していく方針を転換していった話をご紹介します。
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
To all who Think Themselves a Programmerより。 サンフランシスコのある会社での求人なのだが、この会社では書類選考として、どの言語を使用してもいいので最悪なHelloWorld(画面にHello Worldと表示させるだけのプログラム)を書いてもらい、それを採用基準にしている。 最善のコードではなく、最悪な手法で試すとはなかなか面白い。言語選びなどでも個性が出るので、その人の潜在的なスキルが試される。日本じゃこんな手法を採用している企業なんて少ないよなぁ。 採用された例 原文より抜粋して掲載。変態的(褒め言葉)なHello Worldの世界へご招待。 その1 y = lambda { |f| lambda { |x| lambda { |n| (f.call (x.call x)).call n } }. call lambda { |x| lambd
プログラマの方、もしくは趣味でプログラミングをしている方に質問です。 あなたが読んでためになった、またはプログラマなら読んでおくべきだと思うソースコードはなんですか？教えてください。 ネットでダウンロード可能なものでお願いします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
