はてなブックマーク

本項はFindy様のイベント 仕様駆動開発（Spec-Driven Development） Lunch Talk で発表した発表原稿を、加筆修正したものになります。 スライドはこちら 生成AI時代のドキュメント基盤 - Docswell 生成AI、活用されていますか？ 生成AI、活用されていますか？ 私はもう毎日、どっぷりつかっています。 仕様駆動開発にも注目 そんな中、仕様駆動開発も注目を集めてきました。 AWS - Kiro GitHub - Spec Kit Fission-AI - OpenSpec gotalab - cc-sdd ドキュメントの重要性 生成AIの活用が進み、ドキュメントの重要性が再認識されています。 これらの仕様駆動開発ツールの登場は、ドキュメントの重要性が増していることのひとつの表れだと解釈しています。 ドキュメントの2つの課題 これはあくまで私個人の考えで

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

はじめに Claude Codeが凄い、Codexが凄い。新しいモデルが凄い、○○は今日からはもうゴミだ。 そう言って、AI関連ツールにオールインしている人も多いように見えます。 でも、ITエンジニアがAI時代の今、本当に投資すべきはAIツールの活用方法ではないと私は思います。 短期的には 私は、AIへのインプット効率・品質を最大化することにこそ注力すべきだと考えています。 もちろんこれは、AIを軽視している訳ではありませんし、AIツールの利用習得に時間を使うなということではありません。 AIに限った話ではありませんが、学習においても（もとは経済学の用語ですが）収穫逓減の法則が働きます。 たとえば、つぎのようなイメージです。 習得度 習得コスト 生成AIがもっとも素晴らしいところの一つは、道具自体が道具を使う最適な方法を自律的に解決する方向に進化していることです。 そのためこの法則はより顕

たびたび次のような言説を見かけます。 生成AIの出力はレビューが必要なのでITエンジニアは不要とならない 生成AI時代のITエンジニアにはレビュー能力が求められる 私はこの発言は本質を捉えていないと考えています。 生成AI時代のITエンジニアに求められる能力は？ 適切なコンテキストを与える能力 その結果である生成AIの出力を評価できる能力 上記のプロセスを蒸留し続けられる能力 私はこれらが生成AI時代のITエンジニアに求められる能力だと思っています。 「レビューできる」のは、そもそも「適切なコンテキストを与えられる＝仕様を理解し言語化できる」からレビューできるわけです。 このとき本当に大切なのは、生成AIに適切な粒度で正しいコンテキストを言語化して与えられる能力で、レビュー能力はその付随的な能力に過ぎません。 レイヤーは上がり続ける そして現在は生成AIとの境界がコーディングになっているケ

Agent HQというサービスをご存知でしょうか？ Agent HQのご紹介: あらゆるエージェントを、あなたのワークフローに 10月末のGitHub Universe 2025で発表されたもので、実際に直後からCodex CLIが利用できる状態になっていました。 それが今朝（2026年1月28日）になって、Insiders環境でClaude Codeも利用できるようになりました！ これでGitHub Copilotのプランを契約すると GitHub Copilot(& Copilot CLI) Codex CLI Claude Code という3つのAIコーディングエージェントが利用できるようになりました（まだPreviewですが）。 ただ現在のCopilotのプランは、Claude CodeのMaxに該当するようなプランがなく、一定規模以上は従量課金になってしまうため、フルコミットで使

「AIに任せるより自分でやった方が早い」 「AIの書いたコードなんて使い物にならない」 「結局最後は人間が直さないといけない」 私も以前はそう思っていましたし、現在でもSNS上ではそういう意見をよく見かけます。 でも、その甘えは近い将来に組織とあなた自身を殺しますよ？ これまでは許された これまでも「人に任せるより自分でやった方が早い」という考えは、「良くない仕草」として知られてきました。 後進が育たず組織が成長しませんし、結果「当たり前に自分ができる仕事」が自分から手離れせず、自分の成長機会を失うからです。 とは言えこれまでは、そういう甘えも部分的に見逃されてきました。 その仕事を後進に与えなくても、後進はなんだかんだ仕事をこなしていく中で成長していくからです。ベストではないまでも、後進も組織も自分も、大きな損失を被ることなく、なんとかやっていけました。 でも、この問題は別です。 これか

2026.01.28 - 追記開始 コメントで教えていただきましたが、設定ファイルで直接設定すればCLIじゃなくVS拡張でもReasoning Effortを指定できるようです。 参考：GitHub Copilot で xhigh（Extra High）推論を使う 2026.01.28 - 追記終了 皆さん、GitHub Copilot使ってますか？私は日常的に使っています。 GitHub CopilotってほかのAIハーネスと違って、サブスクの課金体系が入出力トークン量ではなく、「プレミアムリクエスト」という謎単位で課金されます。 これを実はうまく利用すると、GPT-5.2-Codex xhighでがっつりレビューさせたり調査させても、最安1回4円で使えます。 GitHub Copilotでコスパ良く活用するコツ これにはコツがあって… GitHub Copilot CLIを使う（VS拡

「〇〇さんが紹介していたSkill、便利そうだから使ってみよう」 そんな軽い気持ちで野良Skillsを導入していませんか？〇〇さんが導入したときは、問題なかったかもしれませんが、あなたが導入しようとしたときも安全とは限りませんよ？ はじめに Claude CodeやCodexをはじめ、Skills（エージェント拡張）を共有・配布するマーケットが急速に注目されています。便利なワークフローをすぐに取り込める一方で、Skillsは「設定ファイル」ではなく「実行可能な拡張」である点を忘れてはいけません。 結論から言えば、中身を自分で理解・評価できないのであれば、AnthropicまたはOpenAIの公式マーケット以外は推奨できません。 Anthropic（Claude Skills）：https://github.com/anthropics/skills OpenAI（Codex Skills）

現在、Proがセール中で年間14,500円（月額換算1,209円）となっており、6人でシェアすると一人あたり月額202円で利用可能です。 Google AI プランと料金設定 注意点 AI credits（画像生成系に必要）は同じ枠を共有する ファミリーグループは1年間に1グループしか所属できない 一人が親となって立て替え払いをして個人清算が必要 親の人はGoogle Oneの共有をON（ファミリーグループへの追加とは別で必要） 子となった人は親となった人からペアレンタルコントロールを受ける可能性がある そのためメインアカウントではなく、専用アカウントを作成するのが無難 Ultraプランは年間契約がなく毎月清算が必要で、負担が大きいのでお勧めできない トラブル回避のためにも、Proの年間契約だけの利用に留めるのが無難です。 Googleファミリーグループの条件 公式の記載は下記の通りで、血

2026/01/16追記開始 2026/01/15にGitHub Copilotの正式なプロバイダー提供が始まりました。 https://x.com/jaredpalmer/status/2011803160122097826?referrer=grok-com この方はGitHubのSVPであるJared Palmer氏の発言であるため、信頼性が高い情報と考えられます。 これでOpenAIに続き、GitHub Copilotも正式にOpenCodeから利用できるようになりました。 2026/01/16追記終了 はじめに GitHubのアカウントごとBanされたくなかったら、OpenCodeのサードパーティプロバイダーからCopilotを利用するのは今すぐ止めたほうがいいです。 経緯 2026/01/10近辺で、Claude Pro/Max契約によるOpenCodeなどのサードパーティ エ

Claude Codeで提供が始まり、Codex CLIやGitHub Copilotでも相次いでサポートされたAgent Skills（以後Skills）機能。とても素晴らしい機能だと思います。 ただ、MCPのときにも思ったのですが、Anthropicは新しい機能のプロモーションがとても上手です。上手すぎて結果、過大に受け取って誤解する人を多数生んでいると思います。 本稿ではSkillsの誤解と、本来の特徴について、簡潔に整理しておきたいと思います。 何がまちがっているか？ よく見かける説明はつぎのような内容です。 これまで汎用的であったエージェントに、ドメイン固有の専門知識や、ワークフロー、ベストプラクティスを与えることで、特定の用途に特化したスペシャリストに変革します。 この説明だけではSkillsの本質的な利点を正確に捉えていません。 これだけなら、多くのエージェントでつぎのような

2025.09.22 7:40 全体的にイエス・バッド法になっていたところをイエス・アンド法に書き換えました。身についてないなぁ はじめに たびたび話題になる「技術的には可能です（でも影響範囲でかいし、品質に影響与えそうだし、結構コストかかるし、スケジュールきついし・・・無理じゃね？）」問題ありますよね。 口に出したことより、心の中の声の方がでかいみたいな。 そしてこれは、言われた側からは非常に不評でもあります。 私は比較的最近、この問題とうまく付き合えるようになりましたので、少しアイデアを共有したいと思い、この記事を書きました。 解決策 それは「できる」と「やる」を分離して できる：自分の責任 やる　：相手のバトン（責任） とすることです。 「はい、できます。リリーススケジュール調整が必要になりますが、やりますか？」 「はい、できます。追加コストが発生しますが、やりますか？」 「はい、で

はじめに たびたび話題になるExcelスクショ問題。きっと皆さんも実際にやったことはなくても、小耳に挟んだことはあると思います。 誰もが好きでやってるわけでもなく、ない方が良いと分かっていても、残り続けるExcelスクショ。なぜExcelスクショが必要とされるのか？なくすために何が必要なのか？ 結論から言うと、SIerがテスターを信頼できれば 廃止できます。 本稿では、Excelスクショエビデンスの本質を整理していきたいと思います。 お断り あくまで一般論で、Excelスクショを廃止すべきではないエッジケースはきっと存在します Excelスクショが完全自動化されていて、コストに跳ねないなら無くさなくていいんじゃね？ テスター100人3カ月で集めてこい！みたいなプロジェクトは本稿の対象外です UIは存在するが、人手によるテストがない、完全に自動化された環境は想定外です また異論反論は大歓迎で

なんかClaude Code起動したら、何やら新しいリリースノートが・・・ Windowsサポートが追加されてるぅ！！ ってことで試してみました。 Git for Windowsが必須ですが、まぁ開発Windows PCにはふつう入ってるでしょうってことで、latestを一応指定して最新版をインストール

追記 Google Workspaceでの利用は、別途有償のGemini Code Assistの契約が必要かもしれません。文書みると不要に見える記述もありますが、そうでもない記述も散見されるためご注意ください。 はじめに Google の Gemini CLI を使用する際、認証方法によってプライバシーポリシーが大きく異なります。特にAPI無料サービスでは、プロンプトや回答がGoogleのモデル改善等に利用され、オプトアウトはできません。そのため、センシティブな情報や個人情報は送信しないよう、利用者自身が注意する必要があります。 Gemini CLI の認証方法とプライバシーポリシー比較 以下の表は、Gemini CLI の5つの認証方法におけるプライバシーポリシーの違いを一覧にまとめたものです： 注意事項: 個人向けGoogle認証のオプトアウト操作はGoogle Code Assis

はじめに .NET Frameworkと.NET 8.0-windowsで、System.Drawing.Bitmapに依存した実装に十年以上も縛られ続けてきました。 いい加減、真面目に非Windows環境での動作に対応しようという事で、各種画像ライブラリーについて真面目に評価してみました。ただし、あくまで画像ファイルからのデコードと二値化処理に特化した評価になっていますので、かなりニッチな評価だとは思います。 参考になるようであれば、ぜひご利用ください。 評価内容 JPEGと二値のTIFF、WebPの3種類の画像ファイルをデコードし、画像解析用の二値のバイト列へデコードする。 評価結果 先に結論だけ記載すると、つぎのようになりました。 ImageSharpのJPEGデコードアルゴリズムが、System.Drawing.Bitmapと微妙に異なっていました。 目視では分からないレベルだとは

解法 C#でデータ保護API（DPAPI）を使用して機密データ（パスワードやAPIキーなど）を安全に暗号化・復号化する方法を紹介します。DPAPIを使用することで、Windowsの組み込み機能を利用して簡単かつ安全にデータを保護できます。 以下に具体的なコード例を示します： using System; using System.Text; using System.Security.Cryptography; // 暗号化関数 static string EncryptSensitiveData(string sensitiveData) { byte[] dataBytes = Encoding.UTF8.GetBytes(sensitiveData); byte[] encryptedBytes = ProtectedData.Protect(dataBytes, null, Data

本稿は「アーキテクチャを突き詰める Online Conference」における発表「なぜDependency Injectionなのか？　～関心の分離と疎結合～」の登壇原稿となります。 発表時の動画アーカイブは後日公開されたタイミングでリンクを追加いたします。 また、本稿のサンプルコードとPower PointはGitHubで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 https://github.com/nuitsjp/WhyDependencyInjection というわけで、本稿の目指すゴールはこちら。 今日は、この場にいる皆さんが「なぜDependency Injectionを利用するのか？」ということを、理解いただくのが本日のゴールとなります。 というわけで本

はじめに WPFで未処理の例外を処理する方針が、毎回わからなくなるので、ここに整理しておきます。 ベストプラクティス つぎのようにApp.xamlのStartupにイベントハンドラーを追加して private void App_OnStartup(object sender, StartupEventArgs e) { DispatcherUnhandledException += (o, args) => { // ログ出力処理 args.Handled = true; // 例外処理の中断 if ( /** アプリケーションを継続可能か判定する **/ ) { // アプリケーションが継続実行可能な場合 // ユーザーへの適切な通知処理など } else { // アプリケーションが継続不可能な場合 // ユーザーへ適切に通知したのち、リソースを解法してエラーとしてアプリケーションを終

はじめに たとえばテストなどにおいて、最初からテストデータが用意されているDBを用意しておきたいというのは、ありがちな要求なのではないでしょうか？ SQL Serverでそんなイメージを用意したいと思ったのですが、公式で紹介されている方法は 初期化済みのSQL Serverイメージの作り方 ではなく 起動時に初期化するSQL Serverイメージの作り方 になっていて、ちょっと欲しいものと違います。 テストで何度も繰り返し実行されるので、最初から初期化しておいてすぐ使いたいのです。たとえばSQL ServerのサンプルDB「AdventureWorks」の初期化には30秒程度かかりますので、これを可能な限り0にしたい訳です。 というわけで、本稿ではその方法を解説したいと思います。 概略 マルチステージビルドを利用して初期化済みのDBファイルを作成し、イメージ内にコピーしておく。 起動時は初

はじめに 本稿は「.NET 6移行祭り！ C# Tokyo」イベントで発表した「金融の基幹システムを1年半かけて .NET 6に移行した話」の内容を文書化したものです。 [2022.08.28追記] さて、はじめにおことわりを。 おもったより大きな反響があって、想定より多く読まれており、とくに正しく伝えられていない箇所があると思い、少し補足を入れました。 ここで基幹システムといっていますが、金融の勘定系システムという意味ではありません。 基幹システムというとCore Systemという意味（これは勘定システムでしょうね）と、Mission Critical Systemの2つがあると思います。 本稿の対象は後者で、システムのお客様が、Mission Critical Systemと判断されて基幹システムとして扱われています。 金融の勘定系とは規模や複雑性、クリティカルな度合も異なりますが、

はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる

これまでの個人的な経験や、いま持ってるノウハウを注ぎ込んで、Generic Hostに対応したMVVM画面遷移フレームワーク「KAMISHIBAI」をリリースしました。 NuGet GitHub 利用マニュアル API Reference ViewModelのコンストラクターに引数を宣言することで、専用の画面遷移メソッドをコード生成します。 たとえば画面遷移時にstringをわたす場合、つぎのようにViewModelを定義します。 [Navigate] public class FirstViewModel { public FirstViewModel(string message) { Message = message; } public string Message { get; } }

現在新しくリリースされる.NET向けの素晴らしいライブラリの多くは、Generic Hostを前提として提供されるようになってきていると思います。そしてWPFアプリケーションからそれらを利用するためには、WPFアプリケーションもGeneric Host上で動作させる必要があります。 WPFアプリケーションをGeneric Hostで動かすことは、基本的な動作であればそれほど難しいわけではありません。しかしGeneric Hostのすべてを享受するためには、それなりに工夫が必要です。 そこでWpf.Extensions.Hostingをリリースしました。 Github NuGet Wpf.Extensions.Hostingは、WPFアプリケーションをGeneric Host上で動作させるためのライブラリです。 Wpf.Extensions.Hostingでは、.NET6ライクにGeneri

本稿はC# Tokyo オンライン LT 大会 2021/01にて発表した「C#メタプログラミング概略 in 2021」の発表内容を文書化したものです。 発表時のスライドは以下に公開しています。 C#メタプログラミング概略 in 2021 またサンプルコードは以下にすべて公開しています。 https://github.com/nuitsjp/MetaprogrammingOverviewIn2021 Introduction さてC#9.0のリリースとあわせて、Source Generatorがリリースされましたね。昨今、一部でメタプログラミングが活性化しているように、個人的には感じています。 そこで本項では、C#で利用可能な代表的なメタプログラミング手法について どういったものが存在し どういうときに何をつかえばいいのか？ その大枠を整理してみました。 Attention! 本稿は、可能