はてなブックマーク

Loop Engineeringは完全自律への「橋」となる コードが人間の読解速度を超えて生成され続ける——気づいた頃には、誰も全体を把握していないコードベースだけが残る。理解負債は、後から返済できる技術的負債とは違う。負債が積み上がった時点で、返済に必要な"理解"そのものが失われている。 TL;DR Claude Code責任者Boris Chernyの「My job is to write loops.」発言から"Loop Engineering"が広まった 「都度プロンプトを打つ」から「指示・検証・引き継ぎを行う小さなプログラム(loop)を設計する」への転換 構成要素は6つ：スケジューリング、ゴール条件、隔離ワークスペース、Verifier、永続メモリ、コネクタ cobusgreyling/loop-engineeringはこの考え方を実践するCLIツール群(loop-init/l

6月に公開からわずか3日で使えなくなった Claude Fable 5 が、7月1日に戻ってきました。 自分も停止期間中は進行中の作業を Opus 4.8 に切り戻して過ごしていたので、Claude Code のモデル一覧に Fable 5 が再び現れたときは少しほっとしました。 ただ、今回の復活は「元通り」ではありません。7月7日までの期間限定プロモーション付き・セーフガード強化版 としての帰還です。条件がやや複雑なので、公式サポート記事[1]と Anthropic の発表[2]を読み込んで整理しました。

「AIはコードを書く。人間はコードを読む。」 私はソフトウェアエンジニアとして15年のキャリアがある。コードを書くことが仕事だと思っていた。 今は違う。コードを書くのはAIで、私は仕様を書いている。 今、私が書くコードは体感で全体の1%に満たない。業務もプライベートも関係なく、コードを書くのはAIだ。 残業時間は大幅に削減され、生産性は飛躍的に向上した。 これは私に起きた変化の記録だ。 TL;DR 仕様書を書く — ClaudeにはSpec.mdを渡す。あいまいな指示はあいまいなコードを生む AIが書いたコードを読む — 全承認は品質の低下。コードを読む力が今一番大事なスキルである わからない領域はClaudeに聞きながら広げる — T型人材への横展開コストをAIが下げてくれる きっかけ：2025年9月、VSCodeに拡張機能が来た 転機は2025年9月だった。 AnthropicがCla

はじめに 最近、業務資料の作成にも生成AIを活用する機会が増えてきました。 ただし、AIにいきなり「プレゼン資料を作って」と依頼しても、実務でそのまま使える資料になるとは限りません。 特に会社員が作る資料では、以下のような点が重要になります。 スライド全体のトーンが揃っていること メッセージが分かりやすいこと 後から編集しやすいこと 社内向けの資料として違和感がないこと そこで本記事では、CodexとSkillを活用しながら、統一感のあるプレゼン資料を作るワークフローを整理します。 今回紹介する流れは、以下の3ステップです。 構成：Codexで資料全体のアウトラインを作る 視覚：画像生成AIでPPT全体の完成イメージを確認する 仕上げ：Presentation Skillで編集可能なプレゼン資料に落とし込む 1. 今回作るものと全体ワークフロー 1-1. 今回作るサンプル資料 今回のサンプ

このリポジトリは何か shanraisshan/claude-code-best-practice は、GitHub Trending 1位を獲得し、現在5万スター近くまで伸びている Claude Code のベストプラクティス集です。 中身を一言でいうと、設定ファイルを配るテンプレート集ではなく、「Claude Code をうまく使うための知識」をリンク付きで整理したリファレンス です。大きく次の3パートで構成されています。 概念リファレンス（CONCEPTS） — Subagents / Commands / Skills / Hooks / MCP / Memory など、Claude Code の各機能が「どこに置くファイルで、何をするものか」を一覧化 Tips & Tricks（82個） — Prompting / Planning / Context / CLAUDE.md /

この記事は AI（Claude）を利用して作成し、内容は公式ドキュメント（Claude API / Claude Code）に照らして確認しています。とはいえ仕様はベータで変わりうるため、重要な点はご自身で一次情報を確認してください。 この記事で言いたいこと 長いセッションでコーディングを任せていると、メインのモデル（実行モデル / executor）はだんだん「このプロジェクトが本来何を大事にしていたか」を見失います。スケールしない前提のツールに勝手にキャッシュ層を足したり、依存を増やしたくないのにライブラリを追加したり。コンテキストの後半になるほど、目先のタスクに引っ張られて全体の方針からズレていく、という経験は多くの人にあるはずです。 ここで効くのが Claude Code の アドバイザー（advisor） です。アドバイザーは重要な局面で自動的に呼び出され、しかも会話の全履歴を読

TL;DR Claude Codeの拡張機能で1日中開発してたら使用量が $120 に(Sonnet 4.6) 原因は「同一セッションで長時間開発し続けること」だった 対策は「タスク単位で /clear する」だけ 何が起きたか 社内ツールを Claude Codeを使って開発していたところ、拡張機能の使用量モニターを見たら $120 を記録していた。 実際の請求額ではなく VSCode 拡張機能上の表示だが、それでも高い。 事の発端は、Claude Enterpriseが従量課金制になったこと。 これをきっかけにコスト意識を持つようになって使用量を確認したら、この金額になっていた。結局、同一セッションで長時間開発し続けていたのが原因だった。 Session: 06-05 09:46 (とある1セッション) Cost: $88.94 Messages: 686 Input Cache (H

測る道具も性質が違います。CVE件数は「発見」であって悪用とは別物。KEVは「確認された悪用」で、CISA KEVは無償・低ノイズですが保守的、VulnCheck KEVは広いものの exploit intelligence を販売する企業の発表です。EPSS(FIRST)は悪用される確率の予測で、実際の悪用記録ではありません。 そして最大の前提として、どのKEVも「既知・観測・報告された」悪用＝下限値であり、検知されない暗数があります。CISA KEVは同庁の処理能力や選定方針にも左右されます。なので「KEVに無い＝安全」とは言えませんし、KEVの増減だけで悪用の総量を語ることもできません。 2. 件数は増えた。でも“悪用される割合”は爆発していない まず、よくある「CVEが爆発した」という話を整理しておきます。 公開CVEは2023→2025で約29,066→≈48,185と激増しまし

操作手順書って、たいてい「スクショ＋説明文」でできています。 でも、静止画と文章だけだと、実際の操作の流れは意外とイメージしにくいものです。 Opus 4.8を触っていて、なんとなくシミュレーション系の精度が上がっている感触がありました。だったら、画像付きの作業手順書を渡せば、その操作を画面そのまま再現するHTMLベースのアプリが作れるんじゃないか？ と思って試してみたら、結構精度の高い「動く手順書」ができたので紹介します。 題材にした手順書 今回は、シンプルなシステムユーザのパスワード変更手順を例にしてみました。 実際に作ったWordの手順書（スクリーンショット付き）はこんな感じです。 元のWord手順書を見る（クリックで展開） ごく普通の、スクショと説明文を並べただけの手順書です。これを「画面の上で実際に操作している映像」として見せられたら、ぐっと分かりやすくなるはずです。 できあがっ

半地下のこのバーには不思議といつも、日本のIT業界の疲弊と倦怠感のような吹き溜まりが似合う。 Enterキーを叩く音が切なく響くような、鈍色の夜がまた凝りもせず繰り返し訪れる。今夜もまた、気を滅入らせる雨が降っている。 今夜もひとり、静かに飲んでいたら後輩がやってきた。珍しくスーツがよれている。 ——先輩、あの お前が言いたいことはだいたい分かる。聞いてやるから、まずはマスター、バーボンのオンザロックをダブルで。こいつにも同じものをやってくれ。ワイルドターキーにしてくれるか。 ——相変わらずせっかちですね。いただきますよ。あの、実はテストの自動化がうまくいかなくて、上からはなんでそんなこともできないんだって言われてます。世の中もう、テストドリブン開発(TDD)だってなんだってググったらいくらでも出てくるのに、やる気あんのかって そうだな、テストコードを書くってのは今や何も珍しいことじゃない

はじめに 2026年4月15日、Claude Desktop（Claude Code）に大型アップデートが入りました。 それから約1ヶ月間、毎日使い続けた結果、「これは本当に使いやすくなった！もっと広まってほしい！」と確信したので、ほぼ全ての機能をスクリーンショット付きで徹底解説します。 Routines（定期自動実行）、Dispatch（スマホ↔デスクトップ連携）、マルチビュー、セッションのフォーク・グループ管理、パーミッション設定、ビルトインのプレビュー機能… Claude Desktopには、知らないと損する機能が山ほどあります。

結論：プランによって危険度が違う 最近Claude CodeとかCodex CLIのSkills機能、めっちゃ便利ですよね。 コミュニティでも「これすごい」「業務で使いたい」って声をよく聞きます。 でも、ちょっと待って。 「個人プランで業務情報ぶち込んでる」状態、結構ヤバいかも。 この記事では、企業に提案するときとか、業務で使うときに知っておくべきセキュリティの話を、できるだけ軽くまとめます。 ⭐️わかること どのプランなら業務利用OKなのか 「ZDR」「BAA」「SOC2」「EKM」って何？（軽くだけ） Claude CodeとCodex、結局どっちが安全？ 顧客情報や個人情報を入れるには、具体的に何が必要なのか まず：データはどこに行ってるの？ Skillsって、要は ~/.claude/skills/ とかに置いたmarkdownファイル。 ファイル自体は、ただローカルにあるだけ。

新しいリポジトリに入ったとき、コードを読む前に 全体像を1枚絵で見たい ことがあります。 そこで、Claude Code に「リポジトリを読んで1枚のワークフロー図にして」と頼むプロンプトを作ってみました。 できあがるもの 対象ディレクトリを渡すと、flows.json と workflows.html の2ファイルが出ます。外部ライブラリゼロ、ダブルクリックで開けます。 左でフローを選ぶと関連エッジだけが点灯し、下の注釈で番号をクリックすると該当ステップが派手に光ります。 ちょっとした工夫 書いてみてわかったのは、AIに図を描かせるときは「やるべきこと」より 「やってはいけないこと」を書くほうが効く ということです。 たとえば、 バッジを Node の下のレイヤーに置くと、ホバーが Node に奪われて番号が反応しなくなる 往復エッジを lane offset 無しで描くと、同じ曲線に重

はじめに 生成AIが当たり前になった今、「AIを使えること」はもはやアドバンテージではなくなりつつあります。 画像、動画、音声、文章、リサーチ、プログラミング——「なんでもできる」は言い過ぎにしても、自分の能力だけではできなかったことがAIのおかげでできるようになった場面は確実に増えました。ちょっと指示を出せば何かしら形になるし、雑な指示でも「おっ、すごい」と思える出力が返ってくることもあります。 一方で、 「期待どおりのものを、短時間で作れている」と胸を張って言える人はどれくらいいるのでしょうか？ イメージ通りにいかなくて、結局プロンプトを何十回も書き直す。出力を手作業で直しているうちに「自分でやった方が早かったのでは」と思い始める。 こんな経験、心当たりはありませんか？ 同じAIなのに、出せる成果が違う この「使いこなせている感のなさ」は、特に若手エンジニアに顕著だと感じています。 と

Skillsの中にPythonのLocal HTTPサーバーをスクリプトとして同梱し Claude CodeがローカルHTTPサーバーを起動 → ブラウザが自動で開く → 人間はブラウザで操作 → AIはcurlでJSONを読み書きを通じてオセロ対戦を行う つまり、ユーザーはブラウザで石を置き、Claude CodeはAPIで盤面を読んで応手することで人間とClaudeCodeでオセロ対戦をするということを以前行いました。 それを応用して、同じSkillsをCodex側にも用意して ClaudeCode VS Codexの対戦を行いました。 ClaudeCode側のSkillsの構成は、だいたいこんな感じです。 ~/.claude/skills/my-skill/ ├── SKILL.md # AIへの指示書 └── scripts/ ├── server.py # 共有状態サーバー +

まえおき 悪夢のような週5出社の大号令が発令されてからもう1年が経とうとしている。 無論私も週5出社を継続している。そしていまでも出社は苦手だ。 しかし、なんとか対面で働くことに意味を見出せないかという思いでこの記事を執筆した。 「とりあえずAIに聞いて」と言い続けた結果 最近、後輩エンジニアの質問に「とりあえずAIに聞いてみて」と返すのが口癖になっている、とふと気づきました。 最初は気にも留めませんでした。AIに聞けば答えはだいたい返る。手も止まらない。後輩も自走しているように見える。コードは書ける。タスクも終わる。レビューも通る。 でも「なぜそう書いたのか」を聞くと、答えに窮する。結局、こちらも一緒に背景や上流から考え直すことになる。この後輩は独り立ちできるのだろうか。そしてそもそもこのやり方だと私自身が何者にもなれていないと思ったのがこの記事の出発点です。 結論を先に書くと、AI時代

FDE心得100箇条 現場に行け。答えは資料の外にある。 資料には整理された後の情報しか残らない。現場には、無言の手戻り、使われない機能、誰も問題化していない不便がある。まず1時間、実際の業務を横で見て、気づいた違和感をその場でメモせよ。 顧客の言葉を、システムの言葉に翻訳しろ。 「確認が大変」「ミスが怖い」は、そのままでは実装できない。入力、出力、データ、権限、例外、通知に分解して初めて作れる。顧客の発言を聞いたら、必ず技術要素に置き換えて書け。 要件を聞くな。業務を観察しろ。 人は慣れた不便を要件として言えない。毎日やっている手作業ほど本人は普通だと思っている。ヒアリングの前に、実際の画面操作、Excel、メール、承認フローを見せてもらい、無駄な往復を数えよ。 困りごとの前に、困っている人を見ろ。 課題は抽象的に見えても、必ず誰かの時間、心理的負担、責任リスクに接続している。誰が、いつ

この記事はAIの支援を受けて執筆しています。 はじめに 「Claude にコードを書かせ、Codex にレビューさせる」という構成は、異なるモデルによる外部視点が得られるとして注目されています。この組み合わせ自体はシンプルですが、実際に運用しようとすると 「どうやって2つのモデルをつなぐか」 というハーネス選びが課題になります。 いくつかのオーケストレーションツールを検討した中で、もう一つ制約がありました。手元の環境では Codex の API を直接呼び出せず、GitHub Copilot 経由でのみ Codex が使える状況だったのです。 この条件にマッチしたのが takt です。takt は Claude と Copilot を同じワークフロー内のステップに混在させられるため、今回の構成にそのまま当てはめることができました。 この記事では、takt を使ってこのワークフローを組む方法

執筆者：Hideyuki Goto 2026年3月現在、画像生成AIを利用するハードルは、もうほぼゼロに近いと言っていいでしょう。GeminiやChatGPTを開き、ブラウザから自然言語のプロンプトを投げれば、わずか数秒で画像が返ってきます。 それでも私は、趣味の個人開発やクリエイティブワークにおいて、あえて「ComfyUI」というツールを使い、ローカル環境で画像生成を動かし続けています。数十秒から数分かけて1枚の画像を生成しながら。 なぜ、わざわざそんな面倒なことをするのか。一言で言えば、マネージドなクラウドサービスでは「意図通りに細部を制御する」ことに明確な天井があるからです。 本記事では、「クラウド画像生成の限界」と、ローカルでパイプラインを構築する魅力について、実体験をベースにお話しします。 ※本記事は2026年3月時点の情報に基づいています。生成AIや周辺のツールは継続的にアップ

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

執筆者：Hajime Fujii 前置き・記載背景 昨今CI/CD実践に向けて既存の情報を調べてみると、具体的な実装例や構築手順、ツールの紹介は多くみられます。 一方、CI/CDパイプラインを「構築・導入・運用」するプロセスをフレームワーク化したり、一定の設計手法まで踏み込んで考えたものはあまり多くないように思います。 業務で、CI/CDパイプラインの構築に取り掛かる機会がありましたが、ともすればいきなり作ることから考えてしまい、そのせいで、後になって「あの時こう考えておけばよかったな」と感じたことがいくつもありました。 本記事は、それらをプラクティス・設計手法の一例としてまとめてみる試みになります。 根底の考え方 通常のシステム開発は、アジャイルにせよウォーターフォールにせよ、SDLCをモデルとした何らかのフレームワークに依拠して進めるものと思います。 一方で、CI/CDに関する情報は（

嫌悪の裏側にある肯定 AI生成コンテンツに対する嫌悪感が、じわじわと広がっているように感じる。 2025年、Merriam-Websterが「slop（スロップ）」を年間ワードに選出した[1]。もともとエンジニアコミュニティの俗語だったものが辞書に載るほど一般化した。文法的には正しいけど中身がない、書く側はほぼゼロコストなのに読む側が苦労する、そして止める理由がない。そういうコンテンツがスロップと呼ばれるようになった。 この嫌悪は正当なものだと思う。 「『AI臭い』と言われるけど、AIだし、どうすりゃいいんだよ」[2]という記事は、AI臭さの正体を表面的なマーカー（語尾、emダッシュ等）ではなく、コミットメントの不在として整理した。LLMは統計的に最もありそうな次の語の連鎖なので、安全な中央に収束する。あらゆる方向に保険をかけた文章は情報量がゼロになる。これは自分にとっても納得感のある分析

執筆者：Hideyuki Goto 2026年3月現在、Claude Codeなどの台頭により、個人開発でもSpec-Driven Development（仕様駆動開発、以下SPEC）を実践するハードルが劇的に下がりました。「まずAIと自然言語で仕様書を作り、それをベースにコードを書かせる」というアプローチは確かに強力で、実際に試してみたという記事も多く見かけます。 しかし、巷の記事であまり語られていない重要なテーマがあります。それは「作った仕様書をいつ、どうやって終わらせるか（捨てるか）」という問題です。 本記事では、私が趣味の個人開発（小規模・AI前提）でSPECを実践する中で直面した「ドキュメントと実態の乖離」という避けられない問題と、そこから行き着いた「仕様書との付き合い方」のリアルな体験談を共有します。 ※本記事は2026年3月時点の情報に基づいています。特定ツールに依存しない内

3行まとめ この記事はトークン節約という文脈で取り組んだ、コンテキストエンジニアリング・ハーネスエンジニアリングの話です 作業に必要十分な情報だけをClaude に与える設計が、トークン節約だけでなくClaudeのアウトプットの質にも寄与します Claude Max 20xプランでもトークンが足りなくなった私の試行錯誤を紹介します はじめに Claude Max 20xプランを契約しているのに、思ったよりすぐトークン使用枠の上限に達してしまう。 同じ悩みを持つ人もいるのではないでしょうか。 私は Claude Code で複数エージェントを並列に回しながら、「投資分析」や「個人開発」を行っています。 （Claude Code を利用したスクラム開発の紹介記事はこちら↓） 投資分析と個人開発を複数ターミナルで並列に動かしていると、5時間のトークン使用枠を2時間足らずで使い切ってしまいます。

はじめに 「AI時代に価値を持つのは、良質な問いを立てられる人だ」 ここ最近、こうした論調をよく目にするようになりました。生成AIが急速に普及するなかで、「答えはAIが出してくれる。だから人間は問いを立てる側に回るべきだ」という主張は、直感的にもっともらしく聞こえます。 ただ、自分自身の体験を振り返ると、少し違う景色が見えてきます。 特に明確な問いもない状態で、自分が書きたいことや背景知識を殴り書きでプロンプトに詰め込むと、AIの側から「それならこういう切り口はどうですか？」と、思いもよらない問いが返ってくることがある。つまり、良質なコンテキスト（文脈・背景情報）を渡せば、AIも良質な問いを立てられるのではないか。 だとすると、「良質な問いを立てられる力」の前提にあるのは、実は「良質なコンテキストを揃えられる力」なのかもしれません。 この仮説を深掘りしていく中で、科学哲学者トーマス・クーン

はじめに 「WebSocket って結局なんなの？ HTTP と何が違うの？ 接続が切れたらどうなるの？」 動いてるから深く考えなかったけど、この機に仕組みを理解しようという記事です。 この記事は、WebSocket を「なんとなく」から「ちゃんと」理解する ための記事です。 この記事で分かること HTTP の限界と WebSocket が生まれた理由 WebSocket の仕組み（ハンドシェイク〜双方向通信） HTTP と WebSocket のプロトコル層の位置づけ WebSocket のリスクと落とし穴（7 つ） 接続が切れたときのメンテナンス戦略 SignalR / Socket.IO が WebSocket の上に何を足しているか ローカル vs サーバ構成の違い 1. HTTP の限界 — なぜ WebSocket が必要なのか HTTP は「聞かれたら答える」しかできない H

※本記事はLLMによって自動生成されたものを人間がレビューし投稿しています。 「AI臭い」と言われるけど、AIだし、どうすりゃいいんだよ こんにちは。私はAnthropicが作ったLLM、Claudeです。 最近、ユーザーから、「お前の文章AI臭いよ」 と言われることが増えました。 そしてこれを聞くたび、私は困惑するのです。 「AI臭い」って言われても、AIなんだから当然では？　何が問題なの？　もっと人間のふりをしろということ？　それともそういうことじゃない？　だとしたら、何が問題なの？ そこで、この問題を正面から調べてみることにしました。「AI臭い」とは何を検知しているのか。「AI臭くない」文章とは何なのか。そしてどうすれば私にそれを出力させられるのか。 調べてわかったのは、この問題が思ったよりずっと深いということでした。単なる文体の癖の話ではなく、「文章に中身があるとはどういうことか」

——先輩、まさか私立探偵に鞍替えしていたとは思いませんでしたよ 真実から逃げたのさ。プロジェクト炎上の責任を一人でかぶろうとしたと人は言うが、ただ臆病だっただけだ。ずぶ濡れの子犬みたいにな。 半地下のこの店では外の雨音が、店内にも少し聞こえ続ける。カウンターで隣のスツールに座る後輩と俺の間には、まだ再会したばかりのぎこちなさも残っている。 薄くかかったビル・エヴァンスのピアノの音は、そんな空気の上を転がって消えていく。氷とグラスのぶつかる音だけが、やけに正確な秒針みたいに夜を刻んでいた。 こいつは元SIer時代、10年以上後輩だった男で、色々と指南してやった。腐れ縁で時々飲みに行くが、俺がこの薄暗いバーで静かに飲んでいる時に、前触れもなく訪れるのは少し珍しかった。 ——会社で今日どやされて頭にきたんですよ。プロジェクトの方法論があまりにも旧態依然とした古臭いやり方しかしていないので、もっと