はてなブックマーク

長らく Node.js では偶数バージョン (v22, v24 など) が LTS としてメンテナンスされてました。しかし 2027/4 リリース予定の v27 以降はそうではなくなります。Node.js 公式ブログで、v27 以降に取り入れられる新しいリリーススケジュールについて説明されています。 Node.js — Evolving the Node.js Release Schedule かいつまんで説明すると: major リリースは年2回から年1回となる 奇数番号だけでなく全てのリリースが LTS となる 早期テスト目的で利用されてた奇数リリースは alpha チャンネルで代替される alpha 期間は約半年確保 v27 から新スケジュールで運用開始 暦に合わせた番号のバージョンがリリースされる 2027 年なら v27、2028 年なら v28... 公式ブログの説明によると

エムスリーのソフトウェアエンジニアの伊藤です。デジスマチームのブログリレー2日目の記事です。 チームではチームリーディングとプロダクトマネジメントを主に担当しています。 はじめに コンテキスト・エンジニアリング AI Ready なコードベースにするためのドキュメント管理 プロダクト画面仕様書 ADR Design Doc API 定義 (Protocol Buffers) まとめ We are Hiring! エンジニア採用ページはこちら エンジニア新卒採用サイト！ ！ カジュアル面談！ ！ はじめに 最近のプロダクト開発では、AI Agent を活用する機会がどんどん増えてきましたよね。 ただ、いざ導入してみると、従来の開発プロセスやコードベースのままだと AI Agent に思うようにコードを書いてもらえなかったり、コードレビューが滞ったり……。 世の中で言われているほど開発生産性が

こんにちは。Findy Tech Blog編集長の高橋（@Taka_bow）です。 前編では、Gene Kim氏の26年にわたるDevOps研究の旅路、DORA研究によるハイパフォーマーの実態、DevOps Enterprise Summitの多彩な事例、そしてスティーブン・スピアー博士との共著『Wiring the Winning Organization』から導かれた"勝つ組織の魔法"のフレームワークとカウチのメタファーを紹介しました。 後編では、この魔法を解き放つ3つのテクニック ── 巧遅（前倒し）化（Slowification）、単純化（Simplification）、増幅（Amplification） ── を具体的な事例とともに紹介します。そして最後に、Gene Kim氏自身が体験した生成AIとバイブコーディングの世界をお届けします。 前編はこちら tech.findy.co

AIエージェントにGodotのゲームを作らせることが可能になった。となればやることはただ一つ。Godotゲームの自動生成である。 このプロジェクトでは、AI に小さな Godot ゲームを素早く作らせ、人間が遊んで感想を返し、AI がそれを受けて改善する、という制作ループを定義している。できれば全自動でイケてるゲームを作って欲しかったのだが、今のAIにはまだ無理である。しょうがないので人間がAIにこうしろああしろと指示してまともなゲームにする。いつものワークフローである。 8つのフェイズから成る実行手順は、 AGENTS.md にまとめられている。Phase 1〜4 でゲームの仕組み・見た目・音を設計し、Phase 5 で実装、Phase 6 でヘッドレステストによる検証、Phase 7 で改善案の提示を行う。ここまではかなりの部分を AI に任せられる。動くゲームを作ること、入力が通るこ

こんにちは、SmartHRでアジャイルコーチをしている@wassanです。 2026年2月18日、製薬アジャイル勉強会でSmartHRにおける組織アジャイルの実践についてお話ししました。前半はスクラムのスケーリングをテーマに語りながら、後半では「感情知性」（EQ）という一見アジャイルから遠いテーマを取り上げました。会場ではこの組み合わせに違和感を覚えた方もいたかもしれません。 なぜ、スクラムのスケーリングとEQがつながるのか。当日の内容をふりかえりながら、あらためて自分の考えを整理してお伝えします。 SmartHRで起きていたこと SmartHRの労務ドメインでは2025年、急成長する組織の中で「チームの判断は正しいのに、全体がうまく機能しない」という問題が顕在化していました。各チームがそれぞれ最適な判断をしていても、全体の方向性とのズレ、チーム間依存の増大、技術的負債の蓄積が起きていたの

株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。 ヘンリーでは以前から開発にClaude Codeを用いていましたが、最近はSkillの活用などでClaude Codeの性能をもっと引き出そうとする動きが活発になっており、ブログでの発信も増えてきています。 Claude Code を活用した電子カルテの外部連携仕様書メンテナンス自動化の取り組み - 株式会社ヘンリー エンジニアブログ 今回は私が以前に作成したSkillをチームの共有物として管理・展開する際に気付いたSkill管理の課題と対策について話そうと思います。 以前作ったSkillの紹介 起票されたIssueの中身を確認・追加調査をしたうえで実装からPR作成までを全自動で行うOrchestrator型のSkillです。（以降 dev Skillと表現） dev.henry.jp このdev Skill作成は元々チ

こんにちは。Findy Tech Blog編集長の高橋（@Taka_bow）です。 本記事は、2025年7月にファインディが開催した「開発生産性Conference」のキーノートスピーカーとしてお招きした Gene Kim氏 の基調講演を、日本語の全文書き起こしとしてお届けするものです。 Gene Kim氏は、ベストセラー『The DevOps 逆転だ！（The Phoenix Project）』『The DevOps ハンドブック（The DevOps Handbook）』の著者であり、1999年から26年にわたり高い成果を上げるテクノロジー組織の研究を続けてきた人物です。 本講演では、DORA研究の成果、勝つ組織に共通する普遍的な原則、そして生成AIがもたらす変革について語られました。 前編では、DORA研究によるハイパフォーマーの実態、DevOps Enterprise Summit

Qwen3.5の中規模モデル(122B/35B/27B/9B)をコーディングエージェントで試してみます。 結論としては、122Bは使える、27Bはなんとか、35Bはストレスに耐えながら、9Bは全然むり、という感じ。 27Bは修正で関係ないところを壊す、35Bは修正として関係ない作業をする、9Bはコンパイル通るコードを書けなかった。 Qwen3.5シリーズの全体的に、395Bまで含め、難しいコードや問題特定は不得意だけど、サイズ相応にそこそこコーディングにも使える、というところ。 ただ、どのモデルもOpenCodeで問題なく動いていて、エージェント対応は完璧です。 コーディング以外だとどのモデルもかなり使えます。 あと、122Bは中規模というにはでかすぎんか？ってなりますが、メインメモリが多く積んであってがんばれば16GBメモリのゲーム用GPUで動きそうなので。 9Bはリリースは4Bなどと同

はじめに こんにちは。GMO Flatt Securityのセキュリティエンジニアの松井（@ryotaromosao）とチョン（Eui Chul Chung）です。 皆さんは、「署名付きURLにおけるパストラバーサル」の脆弱性をご存知でしょうか？ Webアプリケーションで署名付きURLを実装する際、AWS公式のSDKを用いることが多いかと思います。過去にはその公式SDK自体にパストラバーサルの脆弱性が見つかった事例がありました。また一方で、公式SDK側では正しい対策がされているものの、アプリケーション開発者の実装ミスによってパストラバーサルが引き起こされてしまうケースも存在します。 本記事では、実際にAWS SDKで見つかった脆弱性の事例を交えながら、コードベースで署名付きURLにおけるパストラバーサルの脆弱性を深掘りしていきたいと思います。また、後半では、SDKを利用するアプリケーション

はじめに こんにちは。tacomsエンジニアの @ikuwow です。 tacomsでは約1年前から、Cognition AI社の自律型AIソフトウェアエンジニア「Devin」を業務に導入しています。 日常的な開発タスクに活用し、生産性向上に大きく貢献してくれています。 https://devin.ai/ そんな中、珍しく本番障害にまで至ったケースがありました。 この記事では、そのインシデントの経緯と、そこから得た学びを共有します。 何が起きたか 2026年2月某日の夜、本番APIの特定エンドポイントでエラー率が突然100%に達しました。 自動障害検知Botがアラートを発火し、インシデント対応が始まりました。 エラー率が突然100%に急上昇した様子 調査を進めると、大量の500エラーがすべて同一のIPアドレス、同一のUser-Agent（python-requests）、同一のエンドポイン

時限式の許可を与える allow-until / その場でセッションを分岐する side-fork について いまいち知られていない挙動として、Claude Code の SKILL.md には実行時に値が展開されるプレースホルダが用意されている。 code.claude.com $ARGUMENTS は slash command 時代からおなじみだけど、配布したスキルのスクリプトの参照に便利な ${CLAUDE_SKILL_DIR} などが定義されている。${CLAUDE_SESSION_ID} もあってセッションごとに一意な ID が入る。これを利用すると楽しいプラグインを作れるので紹介するぞ。 /allow-until: 一定時間だけセッション単位で全てのコマンド実行を許可するプラグイン allow-until /allow-until と打つと、一定時間だけ Bash コマンドの

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらっている戸田です。 ファインディでは要件定義から設計・タスク分解・Issue生成までをAIに任せるカスタムコマンドを開発しています。 tech.findy.co.jp 今回は、そのコマンドで生成したIssueをAIエージェントに渡したときに、どう並列実装まで自動化しているかを紹介します。Git worktreeとClaude CodeのAgent Teamsを組み合わせることで、依存関係を考慮しながら複数のIssueを並列にPR作成まで進められます。 Git worktreeとは 依存関係グラフで実行レイヤーを決定する Claude CodeのAgent Teams機能 Team LeadとWorkerの役割分担 IssueごとのWorktreeで並行実装を実現する merge-gateによるレイヤー間の同期 Work

Claude Codeでgh apiを使って情報を取得しようとすると、毎回権限プロンプトが表示されてつらい。例えば以下のようなただコミット一覧を取得するだけのコマンドでも、毎回許可が必要になる。 gh api "repos/anthropics/claude-code/commits?per_page=100&page=1" かといって利便性のためにgh api全体に対してallowを設定するのは怖い。ghコマンドはissueの作成やPRのマージなど書き込み操作もできるため、意図しない操作をしてしまうリスクがある。readonly操作だけに絞って許可できればいいのに、と思っていた。 何かいい方法はないかと調べていたところ、ghコマンドにはGH_CONFIG_DIR環境変数でプロファイルを切り替えられる仕組みがあることを発見した。これを利用してreadonly専用のghプロファイルを用意し、

10X SREの栗原です。 この記事は10X 新春ブログリレー 2026の1月28日分の記事です。 株式会社10Xでは、SREチームとセキュリティチームが合同で「技術改善キャンプ」を定期的に開催しています。 事業の優先度や日々の対応に押されがちな…でも大事なタスクへ、まとまった時間で取り組むためのイベントです。 本記事では、その取り組みの一例として、私が第6回（2026/1/26）で検討した「Terraformを管理するリポジトリのレビュー負荷をAIで減らせないか？」というテーマを紹介します。 なお、今回キャンプ内で実装（PoC作成）まで到達したわけではありません。検討と設計（Design Docの作成）までがスコープです。 技術改善キャンプとは 技術改善キャンプは、平たくいうと「普段は優先度の壁に阻まれがちな改善へ、全員で集中して取り組む日」です。 目的は大きく3つあります。 「やるべき

2026年2月25日、GitHub Copilot CLIがついにGAされました。 github.blog そこで今回はまだGitHub Copilot CLIをまだ見てない/触ってない という人向けに、ざっくりと使い勝手やベストプラクティスを3分で知ってもらえるような記事を書いてみました。 検証のコンテキスト 突然ですが、openapi-zod-clientというライブラリがあります。 github.com openapi-zod-clientはOpneAPI Specに定義された内容をZod Schemaへ変換してくれるライブラリです。一方でZodはTypeScript界隈では言わずと知れた型Schemaライブラリです。parseにより、データがSchemaに定義した型や形式に一致するかを検証することができます。 ところで、Zodは2025年4月のリリースでそれまでのV3からV4へと大

SmartHRでプロダクトエンジニアをしている大澤と申します。この記事では、バックエンドエンジニアである自分がフロントエンドのコードをLLMに頼って実装した際の反省点について紹介します。 現在、LLMはだいぶ良い感じのコードを書いてくれるようになってきています。Claude Opus 4.6が生成したRubyのコードはあまり手直しの必要を感じません。日々驚いています。 ですが、それは自分がRubyとRuby on Railsの知識があるからです。 私はTypeScriptとReactについてあまり詳しくありません。SmartHRでは頼もしすぎるフロントエンドが強い同僚の方々に助けられてコードを書いてきました。 LLMを使えばそれっぽい.tsxを出すことはできます。しかし、フロントエンドの経験に乏しい自分が「良さそう」と思うフロントエンドのコードのレベルは低いです。プロンプトの詳細度やコンテ

今までの人生でプログラムとかした事なかったんですが、chatGPTが簡単に作ってくれるというので、自分もやってみることにした。とりあえずpythonという言語が一番わかりやすいということなのでそれを使ってみた。 作ったのは、 画像を適当に放り込むと全部順番でpdfにしてくれるのとか（そのサイズ指定もできる！） ファイル名を一括で変換してくれるのとか 日記を書くのに使ってるフォーマットを一瞬で生成してくれるのとか 画像を入れると真ん中から二分割して、新しくナンバリングしてくれるのとか 整ってないタテヨコの画像を整形して同じサイズにしてくれるやつとか 手動でやってやれないことも無いが、その作業がめんどくさいやつをプログラムで自動でできるようにしてくれた。 こういう作業をするためのソフトは、市販していたり配布していたりもするけれども、わざわざそういうのをダウンロード、購入して使うほどでもないし、

先日The Wall Street Journalから次のような記事があがっていて、読んでしまいました。Anthropicの哲学者を務めるAmanda Askell氏に関するインタビューです。 https://www.wsj.com/tech/ai/anthropic-amanda-askell-philosopher-ai-3c031883www.wsj.com テック業界での倫理学周りを専門とする哲学者の需要が伸びつつあるという記事はたまに見ますが、実際に働いている人が何をやっているのかは思った以上に明らかになっていませんでした。私も学生の頃政治哲学のゼミに所属していたこともあり、倫理学やそれに近い分野を学んでいた人がテック業界でどのようなキャリアを歩んでいるか少し興味があります。 AIの設計に哲学者はどのように関わっているのでしょうか？Amanda Askell氏自身はClaudeに

LLMは「226-68=」のようなプロンプトを与えると「158」と計算してくれますが、この計算は我々が想像するよりも奇妙な方法で行っていることを紹介します [Nikankin+ ICLR 2025]。 まずは前提条件を確認します。思考の連鎖は使わず、「226-68=」のようなプロンプトに対して「158」のように答えを直接出力する場合を考えます。 一例として Llama3-8B を考えます。Llama3 のトークナイザは 0 から 1000 までの数に 1 つのトークンを割り当てるので、「226-68=」を入力すると、次のトークン「158」が「0」「1」...「157」「158」「159」...「1000」などのトークンの中から、最も確率が高いものとして選ばれます。 ヤニフ・ニカンキンらの発見 [Nikankin+ ICLR 2025] は、Llama3-8B は答えや入力についての粗い条件

はじめに こんにちは、Insight Edgeコンサルタント兼デザインストラテジストの楠です。私は普段、事業会社のさまざまな立場の方と会話させていただき、デジタル・AI活用のプロジェクト企画やそれによる業務変革のご支援をしています。 その中で、私自身が感じており、実際によくお伺いする課題として「研修での知識習得やワークショップでのアイデア発想」と「実業務へのAI活用のギャップ」があると思っています。例えば以下のようなものです。 「全社に向けて生成AIの研修を実施し、環境も整えた。しかし数ヶ月後、現場での日常的な活用が思いのほか進んでいない……」 目まぐるしく技術が進展し、常に新たなリリースが行われる昨今、日々手探りで最善の施策を打たれているAI活用推進事務局の皆様や、現場で変革をリードするマネジメント層・メンバー層の方々にとって、この「研修後の死の谷」は非常に悩ましい課題ではないでしょうか

翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎 第2版 ― エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月6日に発売されます。本書は、2025年4月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture, 2nd Edition』（O'Reilly Media）を全訳したものです。 ソフトウェアアーキテクチャの基礎 第2版 - O'Reilly Japan 本書について 本書は、ソフトウェアアーキテクチャという分野が持つ多様な側面を現代的な視点から整理し、その基礎を詳しく解説した書籍です。本書の第1版は、2020年（邦訳は2022年）の刊行以来、国内外で高く評価され、ソフトウェアアーキテクチャに入門するための定番書としての地位を築いています。 本書の概要について詳しくは、第1

Qwen3.5の小規模モデル、4B / 2B / 0.8Bについて試してみます。 画像認識精度の高さもあって、かなり便利に使えそうです。 LM Studio CommunityのGGUFで、Q4_K_Mを試しています。0.8BについてはQ8_0。 画像エンコーダーの影響で2BはQ4_K_MとQ8_0のサイズがあまり変わらないので、Q8_0で試してもよかった。 (9Bに関しては別枠で) Thinkingのオフ 今回、コーディング以外ではThinkingをオフにしてます。 LM Studioで動かす場合だと、35Bと9BはThinkingのON/OFFに対応したモデルが出てるけど、それ以外はプロンプトテンプレートでenable_thinkingで切り替える必要があります。 現状で、0.8Bと2BはデフォルトでOFF、4BはデフォルトでONなので、4BでThinkingをOFFにするには次の指定

こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。 ファインディでは要件定義から設計・タスク分解・Issue生成までをAIに任せるカスタムコマンドを開発しています。 tech.findy.co.jp このコマンドの中にはAIがタスク分解を行うステップがありますが、分解の粒度が適切でなければ、実装がしやすいどころか混乱の元になります。大きすぎるタスクはレビューが困難になり、タスクを細かく分割しすぎると実装が中途半端でビルドが通らないPRが生まれます。 そこで、AIがタスクを分解する際の判断基準として、具体的なルールを定めました。この記事では、そのタスク分解ステップで使っているルールを紹介します。 AIのタスク分解の粒度が重要な理由 タスク分解の基本原則 分割判断の3ステップフローチャート ステップ1: 動作の独立性（Independence Check）

はじめに こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です！ 本シリーズでは、AI駆動開発における人間とAIの役割分担を、自動運転になぞらえた4つのPhaseで整理しています（詳細は下図を参照）。前回の記事では、人間が運転席に座りつつAIに作業実行を任せるPhase 2として、開発プロセスをサブプロセス単位に分解し、スラッシュコマンドとしてAIに割り当てる実践を解説しました。コマンド単位ではAIが精度よく動くようになった一方で、コマンド間をつなぐ「次に何をすべきか」の判断は常に人間が担っている、という構造的な限界が見えてきました。 今回は、この「組み合わせて回す」役割自体をAIに委ねるPhase 3の設計思想について解説します。私たちが「Pilot-Tower開発」と名付けたこのアプローチが、どういう問いから出発し、どういう思想に至り、どういう仕組