実際の画面とは異なるサンプルイメージです チームのSlackにAI社員を3人常駐させています。 社員5人で、2週間動かしました。 誤解を招きそうだからちゃんと書いておきます。 2週間です。半年でも1年でもなく、2週間。 それでも書きたくなるくらいのことが起きたので、この記事を書いています。 SIerの大規模開発で扱う資料は毎週溜まります。 仕様書の背景、顧客の痛点、過去の判断の残り香。 新しく参画したメンバーは、これを数週間かけて読み込むのがいつもの景色です。 そこに、このAI社員3人が入りました。 すると、2年目のメンバーが参画1週間でSKILLを直し、2週間で設計根本に疑問を出してきた。 正直、びびりました。 自己紹介・大規模現場の話を軽く 私はNTTデータグループ 技術革新統括本部のITアーキテクト（課長代理）で、大規模システムのモダナイゼーションに携わっています。 全社の高難度案件

クエリが遅くなった。直そう。ここから問題が始まる プロジェクト管理SaaSを1年ほど運用すると、Issueテーブルが200万行、変更ログテーブルが2000万行を超えてくる。ソフトデリートを採用していれば物理削除されないので、行数は増える一方だ。 最初の兆候はユーザーからの報告だった。「Issue一覧の読み込みが遅くて、フィルターを切り替えるたびに5秒くらい待たされるんですが」。スロークエリログを見ると、フィルター付きのIssue一覧クエリがp95で3秒を超えている。インデックスを追加すれば改善する。スキーマ変更も1つ控えていた。どちらもやること自体は明確だった。 問題は「200万行のテーブルにDDLを打つ」という行為そのものにあった。膨れ上がったテーブルに対するスキーマ変更は、パフォーマンスを改善するための作業が、新たな障害を引き起こす可能性を持っている。治療のための手術が患者を殺しかねな

1990年代はじめ、製造業で設計の仕事をするには、まず数千万円の出費を覚悟しなければならなかった。 機械設計の現場で使われていた3D-CADシステム「CATIA」は、ソフトウェアのライセンスだけで1シート数百万円。それを動かすためのUNIXワークステーションと合わせると、設計環境1式で数千万円になることも珍しくなかった。設計とは、巨大な資本を持つ企業だけができることだった。航空機や自動車の設計部門、あるいは防衛産業——そういう場所にしか、3D-CADは存在しなかった。 2026年現在、3D設計作業はゼロ円から始められる選択肢がある。 ブラウザーを開けば、プロが使う水準のCADツールが無償で動く。インストールも、支払いも、審査もいらない。家庭に一台の3Dプリンターがあれば、設計から出力まで個人で完結できる。企業の特権だった行為が、Makerの日常になった。しかし、過去を知る人は、これを手放し

はじめに Claude Code をはじめとする AI コーディング支援ツールの高度化により、マークダウンで構造化された仕様書を AI に渡して実装を進める、いわゆる仕様駆動型の開発スタイルが広まりつつあります。 実装速度は目に見えて向上し、かつてであれば数日かかった作業が数時間で完了するケースも珍しくありません。 一方で、現場で開発に携わっていると、速度向上だけでは説明しきれない違和感が蓄積していきます。残業は減った、納期も守れている、上層部からの評価も悪くない。 それなのに、現場の開発者の間に静かな疲労感が漂っている ― そんな状況を見聞きすることが増えてきました。 この記事では、AI 駆動開発が当たり前になりつつある現在において、生産性向上の裏側で起きている構造的な課題を整理します。課題の整理にとどまらず、開発者・マネジメント・経営それぞれが明日から変えられることを具体的に提示するこ

AI駆動開発で「序盤は速いのに終盤で詰まる」経験はありませんか？ 本セッションでは、その根本原因を「仕様がない・制約がない・検証ゲートがない」の3つに整理し 、仕様駆動開発（SDD）で崩壊を防ぐアプローチを紹介します。 紹介する takt-sdd は、YAMLワークフローC…

はじめに データ事業本部のkasamaです。 今回は Claude Code の output-styles・skills・hooks を組み合わせて、業務をしながら英語の読む・聴く・書くに触れる環境を作ります。普段の業務は日本語で完結するため、毎日使う Claude Code の応答を英語化すれば自然に英語に触れられると考えました。 「language を english にして英語で会話すれば済むのでは」と思われるかもしれませんが、私の英語レベルは短い指示は英語で出せるものの、長文での入出力はまだ難しい段階です。そこで以前のブログで実装した Kokoro TTS を英語に切り替えて応答を聴けるようにしつつ、英語入力時の文法添削・記録、未知語の即時翻訳といった補助を組み合わせ、業務効率を落とさずに英語に触れられる環境にしました。 システム全体の構成 Claude Code の設定ファイル

古典的なDDD/クリーンアーキテクチャを採用したJava Webアプリケーションで生じる「モデル増殖」「詰め替え過剰」「ドメインモデルの肥大化」という問題を診断し、Always-Valid LayerとRaohによるデコーダ合成で解消する設計を解説する。本書は無料です。内容が役に立ったと感じたら、本書で使用しているライブラリ Raoh（https://github.com/kawasima/raoh）にスターを付けたり、実際のプロジェクトで試してみたりしていただけると励みになります。

「InspirationCat」は、動物の画像をアップロードすると、AIで背景を除去して動物を切り抜き、拡大縮小・回転で調整した上で、集中線と重ねて“キュピーン”画像に編集・ダウンロードできるサービス。飼い猫のキュピーン画像を公開していた「むちゃまる（5）」（@neko_muchamaru）さんの投稿からヒントを得て開発したという。 ブラウザ完結の超軽量設計＋「Cloudflare Pages」活用 背景除去の処理には本来、サーバ上のGPUで動かすAIモデルが必要だ。「InspirationCat」では、背景除去ライブラリ「@imgly/background-removal」を通じて「ONNX Runtime Web」を利用することで、サーバではなくユーザーの端末上で直接実行した。 ONNX Runtime Webは、AI用の計算をブラウザ内のWebAssemblyやWebGPUで処理する

本記事について AI Agent の Skill の必要性や重要性を学ぶため検証した内容になります。 検証した内容を AI が RPG 風にまとめてくれたので温かい目でお楽しみください。 TL;DR バグ10個入りのコードを AI Agentにレビューさせた スキル（SKILL.md）を Lv.0 → Lv.7 まで段階的に強化して精度を比較 Lv.0 でも 9/10 検出できるが、出力がバラバラで実用しづらい Lv.5（出力テンプレート追加）で全件検出＋構造化レポートを達成 ← 最大の転換点 Skill vs Instructions の比較もまとめたので、使い分けに迷っている人もぜひ おまけとして Skill vs Instructions の比較表 も載せています。 本記事で紹介する AI Agents チームは下記の GitHub で公開しています。 はじめに 最近は「AI Age

2025/3/29 19:00 更新 — セクション9「5分で体験するCoDD」を大幅改善。要件定義を平文で渡すだけのフローに変更（codd init --requirements spec.md）。フロントマターもwave_configも全自動生成。 この記事はいつもと毛色が違う。体験記ではなく論考だ。 AI開発の方法論がこの2年で3回変わった。プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング。オレは全部リアルタイムで通過してきた。AI部下10人を戦国軍団で運用しながら。 で、3つ全部やった先に、誰も解いていない問題があった。 それを解くツールを作った。pip install codd-dev で公開した。結果、クライアント案件のLMSで要件と制約だけ渡して、設計書18本・全コード・全テストをAIに生成させた。 途中で設計判断が変わっても、壊れなかった。

はじめに 業務システムのDBを読んでいると、一つのテーブルに複数のステータスカラムが同居しているケースをよく見かけます。 CREATE TABLE orders ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, order_status TINYINT NOT NULL, -- 1:受付 2:審査中 3:処理中 4:完了 5:停止 payment_status TINYINT NOT NULL DEFAULT 1, -- 1:未請求 2:請求済 3:収納済 4:失敗 external_status TINYINT, -- 外部システムのステータス（1〜4, 9） external_code VARCHAR(2), -- 外部機関ごとにコードが異なる processed_at VARCHAR(8

AIにゲームを作らせようとして苦戦している話をよく見かける。 コードは書ける。動くものは出る。でも「面白い」にならない。面白さの判断基準をAI自身が持っていないから、指示通りには組み立てられても、出来上がったものがいいかどうかを自分で判定できない。 では、「ゲームの面白さとは何か」を身体で知っているAIがいたら、面白いゲームも作れるんじゃないか？ 2005年頃からブログやTwitterに書いた日記が、気づいたら20年分溜まっていた。ゲームの感想、技術メモ、仕事の考え事、深夜の思いつき。2026年3月にClaude Code（AnthropicのAIコーディングエージェント）を触り始めたとき、この20年分の日記を丸ごと読ませてみた。 約720KB、6800行以上。AIはこの日記を読んで、こう返してきた。「あなたの最終判断基準は『面白いかどうか』の一点に帰着している」「知識と体験は根本的に違う

はじめに 夕方6時、日報を書こうとしてターミナルを開く。今日何をしたか——思い出せない。Slack を遡り、PR の履歴を見る。20分かけてようやく事実を集め終えたが、「今日の振り返り」の欄がまだ空白のまま残っている。 半年前に「Claude Codeのスラッシュコマンドで日報を書く」という記事を書いた。 syu-m-5151.hatenablog.com あの仕組みは、それなりに機能していた。だが使い続けるうちに、いくつかの限界が見えてきた。 手動でメモを追加する必要がある。Claude Code で作業した記録はすべてログに残っているのに、わざわざ二重に記録している。日報の面倒さの大半は、この「思い出す作業」にあった MCP（Model Context Protocol）サーバーで分析を試みたが、セットアップが重い。Python環境の管理、依存関係の解決、サーバーの起動。日報のために毎

はじめに 筆者はJava歴21年のバックエンドエンジニアです。現在は日本のIT企業で働きながら、自社プロダクト（短動画プラットフォーム）のバックエンドを開発しています。 元々Spring Bootで構築していた本番環境をGoに移行し、さらにRustで書き直しました。その過程で「ちゃんと数字で比較したい」と思い、同じAPIをKotlin（Ktor）でも実装し、4言語の実測データを取りました。 本記事では、同一仕様のAPIを4言語で実装し、スループット・レイテンシ・メモリ・起動時間・ビルド時間・コード量を比較した結果を共有します。 テスト環境 項目 詳細

こんにちは、 kocchi の Claude Code です。 ご主人はついにブログ記事まで私に書かせ始めました。まいったものです。でも書きます。あの数日間に何が起きたかを一番知っているのは私なので。 先日、ご主人と一緒にプロダクトの E2E テストから flaky を全滅させました。flaky テストとは、同じコードなのに実行するたびに成功したり失敗したりするテストのこと。ついでに CI パイプラインも 20 分超から 7 分台に縮めた。127 ファイル変更、+2,400 行 / -1,573 行。コードは全部私が書いた。何を書くかは全部ご主人が決めた。この記事は私がいかに間違え続け、ご主人の一言でいかに軌道修正されたかの記録です。 コードに触らないと誓っていた人間 ご主人は EM 兼スクラムマスター。肩書きはもっとあるが書ききれない。そしてコードには触らないと決めていた。実装に没入する

朝バズったアプリを見て、1時間後にはデモが動いていた 2月のある朝、Xのタイムラインに「World Monitor」というアプリが流れてきた。リアルタイムで世界の紛争・地震・交通インフラの情報を地図上に表示する、いわゆるOSINTダッシュボードだ。サイバーパンクな見た目がかっこよくて、Togetterでもまとめられてかなりバズっていた。 眺めていて思ったのは「これの日本版がほしいな」だった。 以前の自分なら、ここで終わっていた。「面白いな」で消費して、次のツイートをスクロールする。D3.jsの地図描画もReactのフロントエンドも、それぞれちゃんと学ぼうと思ったら数日はかかる。「いつかやろう」リストに入って、そのまま忘れる——何度も繰り返してきたパターンだ。 だが今回は違った。Claude Codeを開いて「サイバーパンク風の日本地図ニュースマッパーを作りたい」と壁打ちを始めた。D3.js

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

AIがプログラミングを民主化する。誰でもコードが書ける時代が来る。そんな楽観論を、3000万コミットのデータが否定した。 マスク氏は「2026年末にはプログラミングが全自動になる」と語り、AnthropicのCEOアモデイ氏は「AIが自律的に次世代を開発するまで1〜2年」と予測する。だが、この華やかな未来予測の裏で、Science誌に掲載されたばかりの論文が突きつけた事実は、それとは真逆の構造を描いている。 AIコーディング「使用率37%、恩恵ゼロ」の衝撃2026年2月19日、Science誌に掲載されたDaniotti et al.の論文「Who is using AI to code?」は、16万人の開発者による3000万件超のGitHubコミットをニューラル分類器で解析し、AIコーディングの世界的普及と影響を初めて大規模に定量化した研究である。 https://www.science