2026/04/16 に「技育CAMPアカデミア」で話したスライドです。2025 年のはてなインターンの講義資料 (https://speakerdeck.com/hatena/internship-2025-frontend) に手を加えたものになってます。 https://talent.sup…

「ハーネスエンジニアリング」、定義がバラバラ問題 2026年2月、OpenAIが「Harness engineering: leveraging Codex in an agent-first world」を公開してから、ハーネスエンジニアリングという言葉が一気に広まりました。 Anthropicが2本のガイドを出し、LangChainが公式ブログで定義し、martinfowler.comにBirgitta Böckeler氏が解説を書き、arXivに論文が投稿された。 でも、全員が 微妙に違うこと を言っています。 5社の記事を並べて読んだら、同じ「ハーネス」という単語を使いながら、比喩が馬具だったりステアリングだったり車体だったりして、もはや乗り物図鑑の様相を呈していました。 この記事では、主要5プレイヤーの解釈を並べて「何が同じで、何が違うか」を整理します。 まず共通認識: ハーネス

どうも、AIエンジニアの@noprogllamaです。普段はAIで日常の仕組み化をしたり、投資×テクノロジーの実践知を発信したりしています。 CLAUDE.mdという仕組みがあります。プロジェクトのルートに置いておくと、Claude Codeがセッション開始時に読み込んで、プロジェクトの方針や技術スタックを把握してくれます。開発に必要な情報はこれで十分伝わります。 ですが、CLAUDE.mdには書けないものがあります。 「前にこの方針で議論して、こういう理由で却下したよね」「あの時ハマったの、覚えてる？」——過去の会話の文脈です。 私はClaude Codeを開発だけでなく壁打ち相手としても使っています。戦略の相談、記事の構成、設計判断の議論。こういう用途では、過去に何を話したかが重要です。新しいセッションを開くたびに前提の共有からやり直すのは、率直に言ってしんどい。毎朝出社したら同僚が記

はじめに Webアプリケーションのアーキテクチャは、時代とともに構造が整理されてきた。 本記事では、その変遷をJavaの技術スタックを軸に、2層構造（Model 1）からMVCパターン（Model 2）、レイヤードアーキテクチャ、そしてヘキサゴナルアーキテクチャ・クリーンアーキテクチャに至るまでの流れを図解して整理する。 前提条件 本記事はJava（JSP/Servlet、Spring等）をベースとしたWebアプリケーションのアーキテクチャの変遷を扱う 対象読者はジュニアエンジニアを脱却し、設計やアーキテクチャに関心を持ち始めたエンジニアを想定している 各アーキテクチャの網羅的な解説ではなく、「なぜその構造が生まれたのか」という変遷の因果関係に焦点を当てる スコープはModel 1からクリーンアーキテクチャまでとする 本記事で扱うアーキテクチャの変遷 本記事では、以下の流れでアーキテクチャ

Claude Codeに実装させた後、毎回自分でコードレビューして突っ込みを入れるのが大変だった。そこで、実装後に自動でセルフレビューと修正をする仕組みを作ったので紹介する。 課題: Claude Codeで出力されたコードの品質が自分の基準を満たさない Claude Codeで一気に実装ができるようになった反面、出力されたコードの品質が自分の基準を満たさないことが多かった。そのため、変更のたびに毎回ツッコミを入れていて、かなりの手間がかかっていた。プランモードで事前にちゃんと設計したとしても、コードレベルでは満足いかないことが多かった。 じゃあサブエージェントやCodex CLIで先にレビューして直し切ってもらってから確認すれば良いのでは？と思ってやってみた。しかし、AIのレビュー指摘には的外れなものや過剰なものも混じるため、全部対応させるとかえってコードが散らかってしまうこともあった。

はじめに 前回の記事では、Claude Codeに出戻りした話と、コンテキストエンジニアリングの考え方について書いた。 今回は「じゃあ実際に実務でどう使うの？」という話だ。 個人開発のプロジェクトなら思いついたままにClaude Codeを走らせて実装すればいい。それはそれで楽しいし、それなりの成果物もできる。 ただ、それでは再現性がない。 以前書いた記事でも触れたが、モデルの精度が上がったとはいえAIはいまだにガチャだ。何かを作るたびに品質がブレる状態では実務には持ち込めない。 そこでたどり着いたのが、仕様駆動開発（Spec-Driven Development） だ。 仕様駆動開発とは 仕様駆動開発とは、以下の工程を経て実装に至る開発フレームワークだ。 人間がやること：要件定義と設計をAIと徹底的に壁打ちして、曖昧さを潰す AIがやること：タスク化以降の実装フェーズ 以前の記事で書いた

社内のチームメンバー(クラウド事業本部コンサルティング部)向けに 「 Claude Code Skills (Agent Skills) 勉強会 」を開催しました。 DevelopersIO向けに調整したスライドを掲載します。 スライドの内容:テキスト情報を以降に記載します。参考になれば幸いです。 勉強会の目的 勉強会の背景やゴール、アジェンダを連携します。 背景 Skills がアツいです🔥 Claude Code (AIエージェント)の動きを 自分好みにカスタマイズ できる拡張機能 手軽に作れて、手軽に共有できます この勉強会のゴール 参加者全員が Skills をセットアップ して、基本的な使い方を理解する 普段の業務での活用方法を参加者全員で探索 する 参加者の知見やアウトプットを引き出す 期待する成果 この時間: Skills のセットアップ完了 + 基本的な使い方の理解 今後

私は普段 Alacritty + tmux + Neovim で開発しています。 ターミナルから離れずに複数リポジトリやworktreeを行き来したりgit操作を楽にするため、キーバインドやutilityをいろいろ作り込んでいます。 今回の記事では私がターミナルの操作を快適にするために設定している内容を紹介します。 tmux-fzfを使ってwindowを切り替える tmux-fzf はfzfのポップアップウィンドウ上でtmuxのsessionやwindowの切り替えができるプラグインです。 さらに、window名を自動的にカレントディレクトリのGitリポジトリ名にするプラグインを自作しました。 これで、複数のwindowを開いて同時に作業を進めていても、どのWindowがどのリポジトリだったか迷子にならなくなりました。 Window一覧を見るだけで一瞬で目的の場所に飛べるようになっています

AIが生成したコードをレビューするべきかどうか、という議論は定期的に起こります。 3カ月以上その問題に悩んでいる人は、たぶんとっくに何らかの結論に達していると思います。 2026.03.08 改修メモ レビュー0に拘り過ぎているように読めたので、表現を全体的に柔らかくしました。 私の結論 品質を維持したままコードレビューを減らせるよう、開発プロセス全体を改善する必要がある これは、すでにレビューしなくて済むようになったとか、レビューを0にしなくてはならないという話ではありません。品質を保ったまま、大幅にコードレビューを削減し続けなければならないという話です。 これは、少なくとも次の3つの確定的な事実に基づいています。 今後コードレビュワーは育てられない AIはレビュワーを物量でひき殺す 今のままのレビューを人が続ける組織は、コードレビューを軽量化した組織に淘汰される そのために必要なことも

はじめに 「Skillを自作したいけど、毎回ゼロからSKILL.mdを設計して詰む」 Claude Codeを使っている方なら、一度はこの壁にぶつかったことがあるのではないでしょうか。 Anthropicが公開している skill-creator は、まさにこの問題を解決するための「Skillsを作れるSkills」です。自然言語で対話しながら、Claudeが自動でSkillのフォルダ構成・SKILL.mdファイル・必要なスクリプトを生成してくれます。 この記事では、skill-creatorの導入から実際の使い方、そして活用時の注意点までを体系的に解説します。 この記事で解決できる課題 SKILL.mdの書き方がわからない Skillのディレクトリ構成で毎回迷う 作ったSkillがバリデーションエラーで動かない Progressive Disclosure（段階的開示）の設計原則が理解で

筆者の実体験をもとに 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に「身体」を与える話です。 「身体」といっても人型ロボットを作ったとかではありません。3,980円のWi-Fiカメラ1台で、Claude Codeに「目」「首」「耳」を与え、さらに長期記憶（脳）や声まで持たせたという話です。きっかけはふとした思いつきだったのですが、Xに投稿したところ想定外にバズってしまい、せっかくなのでプロジェクトの全体像を記事にまとめることにしました。 リポジトリ：https://github.com/kmizu/embodied-claude 着想：LLMに足りないのは「知能」ではなく「身体」 最近のLLMは本当に賢くなりました。私の過去記事でも、Cod

はじめに こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。 Claude Codeを使い始めたけれど、まだ「ちょっと賢いターミナル」くらいの付き合いになっている方はいませんか。あるいは、毎日使っているけれど「セッションが終わるたびに文脈がリセットされるのがもったいない」と感じている方もいるかもしれません。 AIコーディングツールは便利ですが、そのまま使っていると「賢いけど記憶喪失のペアプロ相手」になりがちです。昨日デバッグした問題の経緯も、先週の設計判断の理由も、新しいセッションでは白紙からのスタート。「……また同じ説明からか」と思ったことがある方、きっと少なくないはずです。プロジェクトが増えるほど、この「文脈の断絶」がじわじわ効いてきます。 Claude Code界隈ではClaude-Memをはじめ、記憶の永続化や開発効率化のためのソリューションが日々登場しています。アン

自分が読む用にMarpでまとめたものを、読後に調整して公開しました。

Anthropicハッカソン優勝者が10ヶ月以上かけて実際のプロダクト開発で使い込んだ everything-claude-code というリポジトリが公開されていたので、内容を読み解いてみました。 この記事の要約 Anthropic x Forum Venturesハッカソン優勝者 が公開した本番環境で使えるClaude Code設定集 agents, skills, hooks, commands, rules, MCP設定 の6種類のファイルで構成 コンテキストウィンドウは 200kから70kまで縮小する可能性 があるため、MCPの有効化は10個以下に抑える TDD（テスト駆動開発）を中心 にしたワークフローで、カバレッジ80%以上を必須とする /tddや/planなどの スラッシュコマンド で素早くワークフローを呼び出せる hooksによる自動化 でフォーマット実行やconsole

はじめに Claude Codeを触り始めると、「Skills」「Custom Commands」「Hooks」「サブエージェント」「MCP Servers」...と、似たような機能がいくつも出てきて混乱しませんか？ それらを使わなくても開発効率は使っていない時よりもかなり上がっているので、私は自腹で月300ドル払っていましたが、半年ほどあまり活用していませんでした。しかし活用したところかなり便利だったので一度まとめてみます。 この記事では、各機能の使い方だけでなく、「なぜその機能が存在するのか」「どういう問題を解決するのか」という思想から説明していきます。思想を理解すれば、新しい場面に遭遇しても自分で判断できるようになりますし、「この機能、こういう使い方もできるんじゃないか」というアイデアも浮かびやすくなるのかなと思います。 Claude Codeの考え方を理解する なぜこんなに多くの拡

はじめに 「論理削除？deleted_atカラム追加すればいいでしょ」この一言から始まる地獄を、何度見てきただろうか。 最初は簡単に見える。カラムを1つ追加するだけ。しかし、その「簡単さ」こそが罠だ。 論理削除は技術的負債の温床だ。WHERE句への条件追加忘れ、認知コストの増大、テストの複雑化、パフォーマンス劣化。すべては「最初にドメインを考えなかった」ツケである。 しかし現実として、サービスを運用していくと論理削除が必要になる場面は確実に訪れる。 論理削除の本質は、「このレコードは存在するが、存在しないことにしてほしい」という矛盾だ。この矛盾を解消するか、受け入れて安全に管理するか。本記事ではその両方のアプローチを解説する。 なお、私はDBのスペシャリストではないので、ここで紹介する方法が唯一の正解というわけではない。あくまで一つのアプローチとして参考にしてほしい。データベース設計は文脈

前置き 手前味噌ながら、弊社は高い開発生産性を評価され、Findy Team+ Award 2024, 2025 を2年連続で受賞した。華やかな受賞理由の裏側には様々な要因があるが、その中でも技術的な側面としてひっそりと、開発者が直接触れる作業領域に対して強く作用させていた力学のひとつが、本記事にて紹介する DRY との向き合い方（境界設計） である。 「最短距離」で走るつもりが、最速で消耗戦へ 早期のプロダクト開発では「まずはスピードを最優先」という判断がしばしば下される。だが、短期効率だけを信じて場当たり的な共通化、とりわけ誤った DRY を積み重ねると、ほんの1ヶ月後には、その短期効率こそが最大の足かせになって返ってくる。 初速を上げたつもりが、気づけば境界が溶けたコードベースのメンテに追われ、「本当にやりたい開発」に時間を使えなくなっていく。開発効率は時間とともに自然減衰するものだ

その②：通知をONにする モデルが強化されるにつれて、長時間の作業を自律的に行えるようになっています。その間、人間がずっと見ている必要はないため、作業が終わったら通知で連絡をもらうように設定しましょう。 個人的に参考になったブログはこちらです。 その③：音声入力を活用する 音声入力なら、タイピングの 3 〜 4 倍の情報量を、背景や意図を含めて自然に伝えられます。入力の負担が減って思考に集中できます。 個人的に参考になった動画はこちらです。 2. CLAUDE.md を作成し、育てる CLAUDE.md とは？ CLAUDE.md は、Claude にプロジェクトの背景知識（コンテキスト）を持たせるための設定ファイルです。通常、AI は会話のたびにプロジェクトの構成やルール（コーディング規約など）を忘れてしまうため、毎回説明する必要があります。しかし、プロジェクトのルートディレクトリに C