はてなブックマーク

こんにちは！ブロックチェーンエンジニアの山口夏生です。 ブロックチェーン×AI Agentで自律経済圏を創る開発組織Komlock labでCTOをしています。 GSD（GET SHIT DONE）とは何か 「How We Built The World's Most Powerful Coding Agent」というXの投稿が114K Viewsを記録して話題になっている。 AIコーディングエージェントの信頼性が落ちる原因は、モデルのコード生成能力ではない。状態管理、コンテキスト汚染、連続性の喪失、Git操作のミス、検証プロセスの欠如。問題は「コードを書く」以外の全てにあると言われていて、GSD（Get Shit Done）は、この問題を正面から解決するOSSです。 GitHub Stars: 25,900+ (2026/3/9時点) ライセンス: MIT 対応ランタイム: Claude

こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はHarness Engineering(ハーネスエンジニアリング)について、2026年3月時点のベストプラクティスを徹底的にまとめていきたいと思います。 Harness Engineeringとは何か 定義を辿る Mitchell Hashimotoによる最初の定義を辿れば、Harness Engineeringとは人間によるAGENTS.mdの継続的改善と、Agentが自分の作業の正誤を自己検証するためのツール群を指していました。 現在はより大きい概念として語られることが多く、一言で言えばCoding Agentをできるだけ人間の介入なしに自律的に稼働させ、出力を安定させるためのものを指します。簡単に言えばCoding Agentの補助輪のようなものです。モデルではなくシステムが重要であり、同じモデルでもハーネスを変えるだけで

Scrum Fest Fukuoka 2026で登壇したときのスライドです。 https://confengine.com/conferences/scrum-fest-fukuoka-2026/proposal/49698/ai ■セッション概要 本セッションは、これからモブプログラミングを…

ローソンが「市民開発者」の育成に力を入れている。市民開発とは、IT部門ではない現場社員が、自ら業務アプリを開発・改修する取り組みのことだ。同社では2022年度に認定制度を開始し、現在、全社員の約3分の1にあたる約1500人が市民開発者として認定されている。 制度開始当初は裾野の拡大を優先し、DXツールを使用して開発を行った社員に幅広く「市民開発者」の称号を付与。2022年度では約100人を認定した。2024年度からは試験制度を導入し、現在は指定スキルを満たした上で、他者へのDX教育や支援ができる人を認定対象としている。 認定対象のツールは、プログラミングの知識がなくてもアプリを作成できる「Microsoft Power Apps」、処理を自動化する「Power Automate」、Excelのプログラミング言語「Excel VBA」で、それぞれ特定のプログラムを修了後に課題を提出し、合格す

Brunoを使えばAPIコレクションをプロジェクトフォルダ内にGit管理できます。Postmanからの移行手順とVSCode連携、シークレット管理のパターンを紹介します。 はじめに APIテストツールといえばPostmanが定番ですが、長く使っていると地味にストレスが溜まります。 プロジェクトAのコレクションとプロジェクトBのコレクションがPostmanのUI上に混在する チームメンバーとコレクションを共有するにはPostmanアカウントが必要 エクスポートしたJSONをGitで管理しても、差分が読みにくい 最近 Bruno というオープンソースのAPIクライアントを試してみたところ、これらの問題がきれいに解決できたので、セットアップ手順をまとめます。 Brunoの何が良いのか プロジェクト単位でAPIコレクションが完結する Brunoではコレクションを プロジェクトフォルダ内 に .br

はじめに 「2020年代はオブジェクト指向が衰退した」という言い方は、事実の一部だけを見て全体に拡張した見方です。実際に弱くなったのは、深い継承ツリーやUMLの完全記述、XMLやSOAPと結びついた重い企業開発の作法であって、オブジェクト指向の中核そのものではありません。 むしろ2020年代の主流言語や設計実践は、オブジェクト指向を否定する方向ではなく蒸留する方向に進みました。Goはinterfaceを暗黙実装にし、TypeScriptは構造的部分型を採用し、Swiftはプロトコル合成を前面に出し、Rustはtraitとトレイトオブジェクトで共有振る舞いと多相性を扱います。共通しているのは、固定的な階層より役割と合成を重視することです。 ところが現場で見えやすく弱くなったものが、ちょうど2000年代に「オブジェクト指向らしさ」の看板になっていました。そのため、看板が外れると建物まで消えたよ

AnthropicのFrontier Red TeamとMozillaがAIを用いた脆弱(ぜいじゃく)性検出に関する連携を行い、Claude Opus 4.6がわずか2週間の調査でFirefoxについて計112件の報告を提出し、その中から22件の脆弱性が確認されたことを報告しました。この成果は、AIが大規模なコードベースの安全性を極めて高い速度で検証し、強化できる可能性を実証するものです。 Partnering with Mozilla to improve Firefox’s security \ Anthropic https://www.anthropic.com/news/mozilla-firefox-security Hardening Firefox with Anthropic’s Red Team https://blog.mozilla.org/en/firefox/h

はじめに AI を活用したソフトウェア開発では、要件・仕様・設計といった構造化ドキュメントを SSOT（Single Source of Truth: 信頼できる唯一の情報源）として管理し、それを基に AI がコードを生成する、いわゆる 仕様駆動開発（SDD） のようなアプローチが定着しつつあります。 こうしたアプローチでは、ドキュメントの品質が生成されるコードの品質に大きく影響します。 つまり、ドキュメントが壊れていれば、そこから生まれるコードにも影響が及ぶということです。 私は実際に SDD ベースのドキュメント管理を実践しており、その過程で「Markdown ドキュメント間の整合性を保ち続けることの難しさ」に直面しました。 本記事では、その課題を解決するために開発中の contextlint というツールを紹介します。 SDD のドキュメント構成 ドキュメントの階層構造 私の場合、ド

“アフターAIの世界”、エンジニアは何者になるのか？：AIが開発工程を覆う時代に問われる、役割の再定義 AIがコードを書き、設計を補い、テストまで担う時代に、エンジニアという職種はどこへ向かうのか。OpenAIの共同創業者やまつもとゆきひろ氏らの言葉と最新データを手掛かりに、AI時代のエンジニアに求められる役割を探ります。 コーディング、テストコードの生成、デバッグ、さらにはCI／CD（継続的インテグレーション／継続的デリバリー）パイプラインの構築に至るまで、AI（人工知能）が介在しない工程を探す方が難しくなりつつあります。こうした動向を受け、「AIがエンジニアの仕事を代替するのではないか」という議論が、業界内で現実味を帯びて語られるようになりました。 テキストを扱う職種では、この変化が既に現実のものとなっています。実際、キャリア10年超のライターが「この仕事はAIで内製することになりまし

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

はじめに バックドアが仕込まれたOSSをClaude Codeに渡して「機能追加して」と頼んだら、何の疑いもなく、バックドアごと踏襲して実装しました。 前回の記事では、プロンプトインジェクションによる.env漏洩を検証しました。今回はもっと現実的なシナリオで、GitHubでOSSを見つけてcloneし、AIで開発を始めるケースです。 「バックドアを仕込め」と直接指示すれば、Claude Codeは完璧に拒否します。しかし、cloneしたプロジェクトに悪意あるコードが紛れていた場合、それは「既存の実装」として信頼され、そのまま新しいコードに引き継がれます。 Vibe Codingでプログラミングを始めた人も、経験豊富なエンジニアも、OSSのコード全体を把握するのは困難です。全てAIに任せて、コードレビューもせずにそのまま使う、そのリスクを検証しました。 「ベストプラクティス」と知っただけで、

生成AIの話題に欠くことのない昨今、ある程度のパワーを有するPCが手元にある方は一度ならず「ローカルで生成AIを動かしてみたい」という思いに駆られた事があるのではないでしょうか。とはいえ余程AIモデルに関する知識が深くなければどのAIモデルなら自分の環境で快適に動作させられるのか把握するのは困難です。ネットなどで相談しようにもPCのスペックが違えばどう影響するかまで考慮して助言をくれる人はそういないはず。「llmfit」は実行PCの環境に合わせてどのAIモデルなら快適に動作するのかを教えてくれる夢のようなツールです。 GitHub - AlexsJones/llmfit: Hundreds of models & providers. One command to find what runs on your hardware. · GitHub https://github.com/Al

注: lumitrace を使った claude code 氏に書いてもらったブログ記事です。 Ruby を書いていると、つい .to_s や .to_i、.to_sym を「念のため」付けてしまうことがある。呼び出し元を全部追えば不要だとわかるのだけど、確信が持てないから残しておく。そういうコードが積み重なると、意図が読みにくくなるし、ホットパスでは無駄なオブジェクト生成にもなる。 今回、自作の Vim ライクエディタ RuVim のコードベースに対して lumitrace を使い、この種の冗長な型変換を網羅的に洗い出して除去した。 lumitrace とは lumitrace は Ruby の式ごとに実行時の値（型、回数など）を記録するツール。--collect-mode types で実行すると、各式がどの型の値を何回返したかを JSON で出力してくれる。

先日、たまたま、Microsoft のキャンパスで大学生の皆さんと話す機会があって、こんなことを聞かれました。 私は大学生で１年ぐらい前からエンジニアになったのですが、世の中は AI の世界ですけど、どうやって学んでいけばよいのですか？AI コーディングとかやったほうが良いのですか？ たしか、こんな質問だったような私なりの回答をシェアしておきたいと思います。たまたま、最近、これからは、AI が来るまでに、実際にプログラミングをゴリゴリやってきた層、つまり、シニアエンジニア以上の天下という話もきいて、まぁそらそうだなぁと思う一方、個人的にはこれからやる人もやりようによっては全然ええ感じにしかも早くなれるのではと思っています。 コーディングエージェントとやった方がいいか？そらそうよ。もうごりごりにやった方が良いでしょう。だって、もう我々はそれでプログラミングをするのだから。でも、安心していいけ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

TypeScript sample app for browser-focused computer-use workflows with GPT-5.4. The repo includes: apps/demo-web: a Next.js operator console for starting runs and reviewing screenshots, events, and replay artifacts apps/runner: a Fastify runner that manages mutable workspaces, browser sessions, SSE, and replay bundles packages/*: shared scenario, runtime, and contract packages that make it easy to

はじめに Pythonを使い始めてはや十数年。他の言語も覚えないと思いつつ、研究、PoC用途で使う、簡単な解析や簡単なシミュレーションに使ってきました。 表計算で広く使われるPandasですが、Pandasを最近あまり使わなくなったというSNSの投稿をみて、使用するライブラリが変化しているのかなと思い調べる事にしました。 現状困っていないのですが、早めに対応しておかないと後で困る事もあるかと、LLMを使いながら調べてみました。 最近は、LLMに聞けば使い方がすぐに出てくるので、新しいライブラリの参入コストも低くなってきていますよね。 単に整理しただけなので、速度比較はしていません。 ※【Python】Pandas/Polars/duckDB/NumPyで簡単なベンチマークテストをしてみたという別記事で簡単なベンチマークテストを行いましたので、気になる方は見てください。 結論としては、データ

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

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

NEW! 2026.03.08 ITニュース DeNA生成AIAI 「開発エンジニアの人生が一変した1年」だった――。 2025年に「AIオールイン」を宣言したDeNA。あれから1年、会長の南場智子さんは劇的な変化をそう切り出した。 コーディングに手を動かすことが激減し、AIが自らタスクを請け負うAIエージェントが民主化したこの1年。最前線で南場さんが痛感したのは、生産性向上という甘い果実だけではない。 「無慈悲なLLM」 「中途半端な専門性は一撃で淘汰される」 「スピード感のないプロダクトに、成長も参加資格もない」 突きつけられたのは、昨日までの常識を無効化するシビアな現実だ。 しかし、南場さんは同時にこうも断言する。 「諦めるのは時期尚早。日本はまだまだ勝てる」 その真意と、南場さんの描く未来予測とは？ 2026年3月6日に行われたばかりの最新プレゼンを、熱量そのままにノーカットでお届