Claude Codeは、便利なチャットではありません。 設定、文脈、検証、自動化、並列化まで設計すると、日々の作業環境そのものになります。 この記事では、手元にあるClaude Code運用メモを土台に、Anthropic公式ドキュメント、Claude Help Center、GitHub Actions、MCP、Hooks、Skills、Subagents、非対話モード、情報収集ワークフローまで整理しました。 この記事は全文無料（期間限定）で閲覧できます。 見出し画像はAIで生成しました。 プロンプトはこの記事に掲載中。 Claude Codeは「会話相手」ではなく「作業環境」ですClaude Codeを使いこなせない原因の多くは、プロンプトの上手さではありません。作業環境として扱えていないことです。 公式ベストプラクティスでも、Claude Codeはファイルを読み、コマンドを実行し

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

はじめに こんにちは！Acsim 開発チームの笹沢です。 AI 駆動開発の浸透でコードの生産量は飛躍的に増えました。一方、人間がレビューに割ける時間は変わらないため、レビュー待ちで PR がスタックする場面が以前より増えていきました。 私たちのチームでは「人間のレビューを必須とするもの」と「AI レビューで OK とするもの」を線引きし、セルフマージ制度として日々の開発に組み込みました。直近では PR の 約 8 割が人間レビューを介さずにマージできています。マージまでのリードタイムも短縮されています。 この記事では、セルフマージ制度の設計と運用上の工夫、導入後の変化を紹介します。AI レビューが十分使えるレベルになった今、自チームのレビュー運用を見直したい方の参考になれば嬉しいです。 すべての PR に人間レビューは必要か 最近の AI レビューはコード品質の担保という意味では十分使える

はじめに こんにちは。GMO Flatt Security株式会社 セキュリティエンジニア(兼Claude Codeオタク)の石川（@ryusei_ishika）です。 Claude CodeやCursorなどのAIエージェントを活用したバイブコーディングが急速に広まっています。私自身、社内ではClaude Codeのリリース（ほぼ毎日）のたびにそのリリースノートの重要なポイントを解説しているほか、Biz職向けに「バイブコーディング講座」を実施するなど、社内でのAI活用の普及にも取り組んでいます*1。 リリースノートが公開されていると、出勤後すぐに便利な機能を解説する石川 昨今、AIエージェントを日常的に使い込むなかで、従来の開発では起きにくかったセキュリティリスクが顕在化しつつあると感じています。例えば、先日AIエージェント経由で.envの認証情報が漏洩し、外部サービスのアカウントが乗っ

Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI

大学1年の春、同じ学部に気になる子がいた。 見た目が可愛いとか、話し方が独特とか、そういうありがちな入口だったと思う。たまたまその子の幼馴染と同じサークルで仲良くなって、流れでその子とも話すようになった。 ただ、今思うと、俺は恋をしていたというより、未知の生態を観察していたのかもしれない。 最初に「ん？」と思ったのは、授業のあとに一緒に帰ることになった時だった。 その子が急に、 「ちょっとカバン取ってくる」 と言って、校内にあるよく分からないオブジェの近くの茂みに入っていった。 大学の構内には、誰が何のために置いたのか分からないオブジェがある。新入生の俺にはそれだけでも意味不明だったのに、その子は迷いなく茂みに突っ込み、数秒後、リュックを持って出てきた。 当然聞いた。 「なんでそんなところにリュックあるの？」 すると彼女は、何を当たり前のことを聞いているんだ、みたいな顔で言った。 「重し。

Harness Engineering Meetup Tokyo #1、TOPバッターとして、ハーネスエンジニアリングについての導入的説明を行いました。

2026年4月23日、オープンソースのパスワードマネージャ Bitwarden の CLI パッケージ @bitwarden/cli の npm 版が侵害されました。攻撃者はバージョン 2026.4.0 を公開し、preinstall フック経由で情報を窃取するマルウェアを実行させました。本記事は、手元での検証および公開情報を踏まえ、日本のコミュニティ向けに事象を整理するものです。 追記: 本侵害をCTO米内が解説するウェビナーを4月28日（火） 12:00から開催予定です。申し込みページより事前登録いただければ、どなたも無料で視聴が可能です。 TL;DR - 対応指針 悪性バージョンは 2026.4.0 のみです。2026.3.0（直前正規版）と 2026.4.1（復旧版、正規の Trusted Publishing 経由・provenance 付き）は安全です。 2026.4.0 がイ

こんにちは アクセンチュア北海道オフィス所属の唐津です。 1年ほど前にPMPを取得しました。取得して意味あったな～というのと、最近周りでPMPを取ろうとしている人がいるので、「攻略法」と「取得する意味」を改めて言語化しようと思った次第です。 ただし具体の勉強法（この参考書が役にたった、こういう学習Cycleが良かった）とかは書いてないのであしからず。 この記事は、これからPMPを取ろうとしている人たち、そしていま勉強中で「この量、本当に全部覚えるの…？」と手が止まりかけている人に向けて書いています。受験してから読む記事ではなく、受験準備のど真ん中で読んでほしい記事です。 私自身、PMPを受ける前は学習の範囲が広すぎて胃もたれしそうでしたが結局のところ、 PMPは、暗記で受かる試験ではなかった。世界観の理解で受かる試験。 問題集を周回していたときには見えなかった景色が、「あ、そういうことか」

話題の人気ブログ「おい、」シリーズの著者で、ソフトウェアエンジニアのnwiizoさんによる新連載「生産性を取り戻せ」が始まります。この連載では「仕事の生産性」をあらゆる角度からとらえ、チームで生産性を高めていくためのヒントを探っていきます。 第2回のテーマは「なぜKPIを達成しているのに、チームの生産性は壊れるのか？」です。生産性を「計測」するという行為は、一見理にかなっているように見えますが、実は生産性を壊す「脅威」でもあります。 はじめに 2週間に一度の振り返りミーティング──スプリントレトロスペクティブと呼ばれる場の午後だった。 チームの作業量を示す数字が、2回連続で下がっていた。この数字はベロシティと呼ばれ、タスクごとに振られたポイントの合計で表される。 マネージャーがグラフを画面共有した。右肩下がりの折れ線。「なぜベロシティが落ちたのか、チームで話し合いたい」。全員がカメラの前で

【Harness Engineering入門】AIエージェントを制御するアプローチの登壇資料となります。 https://findy.connpass.com/event/388471/

ボトルネックを見つけて解消する。それで問題は解決するはずでした。 しかし実際には、別の場所にボトルネックが現れ続けます。その繰り返しの中で、問題はやがてコードや工程ではなく、「人と人の間」に移っていく。 TOC（制約理論）の考え方から出発し、複雑な組織における問題の捉え方と、「視点を動かす」という立ち振る舞いを掘り下げます。 ボトルネックを見つけたい ボトルネックが移動する 問題の種類が違う──工場から熱帯雨林へ 複雑な現場でどうするか──着眼大局、着手小局 分解した瞬間に壊れるもの 信頼貯金を育てる おわりに──視点を動かす 信頼貯金で変化に対応する ボトルネックを見つけたい 予算が足りない。時間がない。その割にやることが多過ぎる。 開発の現場で日々直面するこうした問題には、ある共通点があります。問題が「見えている」ということです。誰が見ても「ここが詰まっている」と分かる。テストが手作業

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

ナタリー 音楽 特集・インタビュー 向井秀徳が語るテレキャスター論～新番組「Fender Radio Tokyo」収録レポート＆インタビュー 「Fender Radio Tokyo」 PR 2026年4月22日 愛でてりゃいいんですよ ──収録を終えての率直なご感想を教えてください。 この雨の日に原宿でギターの話をする、というのがいいなと思って。 ──雨の日がいい？ 雨降りの朝に……（少し考えて）とても切ないや。なんとなくたそがれて、相づち打つよ。僕の弱さと君のジンジャーエール。なんとなく。安心な俺たち、旅に出ようぜ。安心な僕らはギター弾こうぜ。……みたいな感じですかね。 ──（笑）。 ところどころに不安を生じさせるフレーズですけども。 ──JASRACあたりからおとがめがありそうな。 ねえ？ ──（笑）。ラジオでギターのことを話すのは、いいものですか？ まあ、飲み屋が一番楽しいでしょうね

画像生成AIは、もはや“きれいな絵を出す道具”ではなくなりつつある。OpenAIは4月22日、画像生成モデル「ChatGPT Images 2.0」を発表し、ChatGPT、Codex、APIで提供を始めた。ThinkingやPro系モデルと組み合わせた高度な出力は、有料プランPlus、Pro、Businessユーザー向け。 画質そのものよりも「どれだけ指示どおりに作れるか」に軸足を移したのが最大の特徴。OpenAIによれば、Images 2.0は細かな指示への追従、オブジェクト同士の位置関係、そして画像内のテキスト描写を大きく改善した。従来の画像生成でありがちだった「だいたい雰囲気は合っているが、細部が崩れる」という弱点をつぶしている。 特に強みを持つのは、文字を含むビジュアルだ。UIモック、ポスター、説明図、マンガ、広告素材のように、画像の中に読める文字が必要な場面では、これまでAI画

はじめに プログラマーの三大美徳は、ラリー・ウォールが Perl の文化とともに提示した有名な言い回しですが、日本ではそれが単なる Perl の格言にとどまらず、広くエンジニア一般の心得として知られるようになりました。現在の Perl 公式文書でも、この三つは「Laziness, Impatience, and Hubris」として明記され、由来はラクダ本の通称で知られる『Programming Perl』にあると案内されています。出発点は明確に Perl 文化の内部にあります。 ところが日本語圏では、この言葉が Perl を知らない初学者や転職希望者にまで届いています。技術系媒体や転職媒体、学習媒体に至るまで、三大美徳は「プログラマーに向いている人の特徴」や職業理解の一部として紹介されています。一般化の度合いが、日本ではかなり高いのです。 ここで問いの立て方を少し正確にしておきます。英語

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディではClaude CodeのスキルやカスタムコマンドなどをPlugins経由で社内展開しています。 tech.findy.co.jp コードレビューやタスク分解といった開発業務の効率化が進む一方で、登壇準備はまだ手作業の割合が大きい領域です。話す内容を固めて、構成を考えて、スライドに落とし込んで、デザインを整えて……。発表の本質は「何を伝えるか」なのに、準備工程に時間を奪われがちです。 本記事では、この課題に対処するために社内Pluginsに作った登壇スライド生成スキルを紹介します。壁打ちによるコアメッセージの言語化からMarkdownスライド生成、Google Slidesへのエクスポートまでを一気通貫で行えるもので、壁打ちから完成まで30分で終わるようになりました。 登壇準備にかかる時

エンジニアの吉田です。 フォルシアにはdevゼミという文化があり、エンジニアが講師となって自身の詳しい分野に関する講義やハンズオンを行っています。 私もこれまでに何度かSQLチューニングを題材としたdevゼミを開講してきましたが、いずれもこちらが一方的に話すという形式に終始しており、実際に受講者が手を動かせる形式での講義も望まれていました。 色々とやり方を模索した結果、コンテスト形式で実際にPostgreSQLのチューニングを行ってもらう、という形の講義を行うことになりました。コンテスト形式での実施にあたりいろいろと工夫した点や学びがあったので、以下にそれらをまとめます。 SQLチューニングをハンズオンすることの難しさ これまでインプット中心の講義を行っていたのは、ひとえに SQLチューニングをハンズオン形式で実施することのハードルが高かった からです。 過去に社内でも何度かチューニングコ