本日も、ネットに流れるトピックから個人的に興味を引かれたものを拾っていきます。
この記事への感想等コメントで頂けるとありがたいです。
プログラミング
Go言語
Building an AI-Powered App Entirely in Go: From Simple Prompt to Smart Pipeline | by Naveen Vandanapu | Nov, 2025 | Medium
本記事は、「Goだけで本番運用可能なAIアプリは作れるか？」という問いから始まり、GenkitとGoを用いてウェルカムメッセージ生成アプリを5段階で進化させていくプロセスを紹介している。 初期版では、文字列入力から文字列出力のシンプルなフローを定義し、LLMに対して明示的なプロンプトとレスポンス処理を行う構成を採用している。 次に、言語・長さ・トーンなどを含む構造化入力を導入し、ユーザーがフォームから細かく条件を指定できるようにしてUXを向上させている。
三段階目では、LLMにJSONでの構造化出力をさせ、メッセージ本文だけでなくメタデータや属性情報を型付きで受け取ることで、LLMを型安全なAPIのように扱う手法を示している。 さらに本番向けとして、生成結果を別のLLMフローでモデレーションし、不適切な内容があればサニタイズ版と元テキスト、理由を併せて返す安全フローを構築している。 最終段階では、自然文の要望からパラメータを抽出し、生成・モデレーションフローへと連結する「スマートフロー」を実装し、ユーザーはただ説明を書くことで安全なメッセージを得られるようになっている。
技術的には、GinとGenkitによる型安全なフローオーケストレーションに加え、Gorilla CSRFをラップしてCSRF対策を行い、環境変数で設定可能なIP単位レートリミットをgolang.org/x/time/rateで実装している。 フロントエンドはTemplとDatastar、Tailwindのみで構成され、SSEを使ってJavaScriptなしでリアクティブUIを実現している。 デプロイはDockerとCloud Runを利用し、Gemini 2.0 FlashやOllamaをモデルプロバイダとして差し替え可能な構成で、実際のコードとデモはGitHubリポジトリとライブ環境として公開されている。 全体を通して、GoとGenkit、少数の周辺ツールを組み合わせることで、観測可能でテストしやすく、安全性に配慮したAIパイプラインを段階的に育てていくアプローチが強調されている。
一般的にPython＋LangChain/LangGraphが主流だが、既存システムがGo統一であること、goroutineや単一バイナリ、interface抽象などGoの特性がエージェント基盤と相性が良いことからGo採用を継続している。
当初は/api/ai/chat1本のエンドポイントにプロンプト構築・Tool登録・LLM呼び出し・SSEストリーミングを詰め込んだ一枚岩構成だったが、OpenAI SDKへの強い依存やToolとインフラの密結合、SSE前提設計、テストの書きにくさなどの問題が顕在化した。
これを解決するため、Model・Memory・Tool・Agent・StreamingといったAI固有の概念をpkg/ai配下に抽象として集約し、OpenAI依存コードはpkg/ai/openai、DBやToolRegistry実装はinfra層、アプリ固有Toolはapplication層へ分離している。
AgentはReActパターンを実装するReactAgentとしてModel/Memory/ToolRegistry/StreamWriterにのみ依存させ、HTTPやSSE/WS/gRPCの詳細はPresentation層の実装に閉じ込めた。
Application層ではUsecaseがModelFactory・Memory・Tool群を組み合わせてAgentを組み立て、Handlerは認証やバリデーション、SSEWriter生成に専念する構造としたことで、モデル切り替えやメモリ実装変更、ストリーミング方式変更、Agent単体テストが容易になったとしている。
本記事では、Goとクリーンアーキテクチャを用いてAIエージェント基盤を再設計し、エージェント・スレッド・メッセージを中心としたスレッド型チャットと、その永続化・実行フローをどのように整理したかが解説されている。
まず、Agents / Threads / Messagesという3つのドメインモデルを定義し、Repositoryインターフェースを介してPostgreSQLに保存する構成とすることで、会話履歴をmessage_indexで順序管理しつつ、将来の編集や最適化に備えたDB設計を行っている。 また、Memoryインターフェースの実装をInMemoryからPostgreSQL版に差し替え、メッセージの可視性フラグを導入することで、ユーザー向けUIと開発者向けログで表示範囲を柔軟に切り替えられるようにしている。
アプリケーション層では、AgentRunUsecaseなどのユースケースを定義し、ToolRegistry・Memory・ModelFactoryを組み立ててエージェントを実行するロジックを集約し、HTTPハンドラはGinを用いた薄い層として認証やJSONバインディング、SSEレスポンスに専念させている。 モデル依存はpkg/ai/openai配下に閉じ込め、ModelFactoryインターフェースを介してOpenAIクライアントを隠蔽することで、将来のマルチプロバイダ対応やローカルLLMへの差し替えを容易にしている。
実装上のハマりどころとして、ユーザーメッセージが二重保存される問題や、ストリーミング中のassistantメッセージが保存されない問題が挙げられ、メッセージ保存の責務をエージェント側に集約することや、SSEで受け取ったトークンを集約して最終回答として一括保存する工夫で解決している。 結果として、従来の「ハンドラにロジック直書き」構成と比べて、モデル差し替えやツール追加、RAGや複数モデル対応、MCP連携といった拡張を、既存のGoバックエンドと同じ抽象化レイヤーの中で長期運用しやすくなったと述べている。
この記事は、GoのORMライブラリGORMのコードジェネレータGenを使い、Upsert時に主キー衝突が起きたとき主キー以外のカラムを一括更新する方法を紹介しています。 使用環境はgorm.io/gen v0.3.27とPostgreSQLで、主キー付きモデルを定義し、clause.OnConflict{UpdateAll: true} を指定して Create を実行することで、主キーを衝突キーとして他の全カラムを更新する実装サンプルを示しています。
Azure DevOps
.githubusercontent.com learn.microsoft.com pubilickey1.jp Hatena Blog などから、Azure DevOpsでもGitHub Copilotに類似するCoding Agentが利用可能になったが、現在はAzure Boardsから利用するに限定され、申し込まないと利用できないプレビュー状態にある。すでにAzure DevOpsではCopilot系機能が一部存在するが、Coding Agentの利用はまだ限定的で、Igniteでデモが行われている。
SQL Server
SQL Server 2025のローカルONNXランタイムは、公式ドキュメントだけでは対応しきれない点が多く、特にトークン化ライブラリ（tokenizer_cpp）はGitHubのフォークされたリポジトリでビルドする必要がある。使用可能なONNXモデルはHugging Faceで公開されているが、モデルによっては「sentence_embedding」出力が必要で、日本語対応のモデルを選ぶと精度が向上する。トラブルシューティングはXEventテレメトリで行うが、エラー内容が具体的に判明しにくいため、詳細なログ確認やモデル出力の確認が推奨される。
RDBMS
RDBの同時実行制御は、複数のトランザクションが同時にデータベースにアクセスするときに、データの整合性を保つための仕組みです。主にロック方式と楽観的制御（オプティミスティック制御）があり、ロック方式では排他制御や共有制御を行い、楽観的制御ではトランザクションの完了時に競合を検出します。代表的なロック方式には2段階ロック（2PL）やMVCC（マルチバージョン同時実行制御）があります。
エージェンティックコーディング・仕様駆動開発
AIによるコードレビューコメントが大量に付くと、重要度の低い指摘や誤ったコメントが混ざり、仕分けコストが増大する問題がある。
この記事では、まずPRに付いたレビューコメントをすべて収集し、妥当性と対応優先度（必ず直す・余裕があれば検討・無視可）をAIに一次判定させる「棚卸し」プロセスを提案している。
GitHub CLIではgh commentではなくGraphQL API経由で未解決レビューコメントを取得し、PRの目的・スコープも踏まえて分類するカスタムコマンドを用いる点が特徴である。
これにより、「AIレビューをさらにAIでレビューする」レイヤーを挟み、人間は一覧化された結果だけを見て本当に対応すべき指摘に集中でき、セッション分割やAI活用の整理にもつながるとしている。
この記事では、GitHubがAIによる開発支援が進むことで、プログラミング言語の選定に変化が生じると予測しています。特に、AIの「ハルシネーション」（誤った出力）が少ない型付け言語、例としてTypeScriptが注目されると述べています。AIがコード生成を補助する中で、バグやエラーの発生しやすい動的型付け言語よりも、静的型付け言語の採用が増える可能性があるとしています。
AI
AWS
このブログは、AWS の開発支援ツール Kiro の学習パスを、読者のペルソナ別に案内するガイドです。 Kiro は「岐路」を意味し、仕様駆動開発（Spec）と Agent Hooks などの機能で、要件定義から設計・実装・運用までを一貫して支援することを特徴とします。 記事では、初めての利用者、Amazon Q Developer からの移行ユーザー、組織導入を検討する担当者、実践的なユースケースを知りたい開発者向けに、それぞれ読むべき Kiroweeeeeeek in Japan の各 Day 記事とワークショップを整理しています。 特に Day7・Day8 による仕様駆動開発と Spec ファイル運用をコアとし、個人とチームの生産性・品質向上を狙う新しい開発パラダイムとして Kiro の活用を促しています。
本
『バイブコーディングを超えて AI時代を生き抜く開発者の未来』は、アディ・オスマニ著で、オライリー・ジャパンから2025年末に刊行される邦訳本です。原書『Beyond Vibe Coding』は同年8～9月に刊行され、AI時代の開発者に求められる新たな姿勢や技術について論じています。邦訳は原書刊行からわずか半年で出たことで、オライリー系では非常に早いペースとされています。
論文・その他
1990年代半ば、インターネットの普及に貢献したNetscapeは、Windowsに同梱されたInternet Explorerとのブラウザ戦争で敗れ、やがてAOLに買収されました。この戦いは、OSとブラウザの統合による市場支配を巡る激しい競争であり、結果としてマイクロソフトが勝利しました。
その後、インターネットの主戦場は検索エンジンへ移り、Googleが市場を支配するようになりました。Googleは2014年にDeepMindを買収し、AI分野でもリーダーシップを発揮しています。現在、OpenAIとGoogleが生成AI分野で覇権争いを繰り広げており、これはかつてのブラウザ戦争の再来とも言われています。
ブラウザ戦争から検索、そしてAIへと主戦場が移り変わる中、技術とプラットフォームの統合が市場支配の鍵となっていることがわかります。
LLMに「信念・願望・意図」を実装するためのフレームワーク「BDIオントロジー」が紹介されています。この手法では、AIの思考プロセスを「信念（Belief）」「願望（Desire）」「意図（Intention）」という人間の心理モデルに沿って構造化し、AIの意思決定理由を透明化できます。オントロジーを用いることで、LLMの行動の背景や論理的矛盾を明確にし、複数のエージェント間での共通言語としても活用可能になっています。
クラウド
Azure
2025/11/29 時点で公開されている Microsoft 関連情報のうち、Official Microsoft Blog、Azure Blog、Azure Updates には特筆すべきピックアップはなく、Microsoft Tech Community から Azure SQL 監査ログの複数 Log Analytics Workspace へのルーティング手順、AI Toolkit と Microsoft Foundry を用いた AI エージェント構築のライブ配信案内、小規模言語モデルでの Function Calling 解説、Azure App Service と AI Foundry の統合サンプル、Windows 管理者向けの .NET EOL 対応、VPN 代替としての Microsoft Entra Global Secure Access 紹介などがまとめられています。 また、Microsoft Developer Blogs から ASP.NET Core OData 10.0.0 Preview 1 のリリース告知、Microsoft Fabric Blog から 2025 年 11 月の Fabric Influencers Spotlight 記事が取り上げられています。
セキュリティ
ブロックチェーンフォレンジック
Bitcoinの「大きな秘密」は、もはや完全な匿名性ではなく、ブロックチェーンの取引記録が法執行機関によって容易に追跡可能になったことだ。2014年以降、ブロックチェーンフォレンジックにより、従来の金融システムよりも資金の流れが明確に追えるようになり、ビットコインは犯罪者にとって逆に大きなリスクとなった。
エンジニア
お仕事
2025年の情シスは、経済動向の不安定さやスタートアップ不況、M&Aの加速などにより業務範囲が大幅に拡大しており、かつてないほど複雑化しています。そのため、情シスの必要性は高まる一方で、採用は極めて難しくなっています。その背景には、多様化する役割や要求されるスキルの高さがあるとされています。
記事によると、Rubyの生みの親であるまつもとゆきひろ氏は、IT業界で出社回帰の流れが強まる中でも、エンジニアにとってリモートワークが生産性やモチベーションを高めると強調しています。彼は「出社させたがるのは、マネジャーの怠慢」とし、現場の生産性や成果を重視する姿勢を強調します。特にエンジニアの業務は成果物の質で評価すべきであり、物理的な出社は必ずしも必要ないと考えています。また、リモートワークによって通勤時間やオフィス環境のストレスが軽減され、個人のパフォーマンス向上につながると述べています。彼の見解は、働き方改革の議論に大きな影響を与えています。
OS
zsh
zellikに紹介されているzshの名前付きディレクトリは、setopt autonamedirsを有効にすることで、変数にディレクトリパスを設定すると、~変数名でそのディレクトリに簡単に移動できる機能です。また、hash -dコマンドを使って直接名前付きディレクトリを設定することも可能です。これにより、よく使うディレクトリへの移動が格段に楽になります。