はじめに 韓国でインターネットバンキングを利用したことがあれば、各種セキュリティプログラムのインストール要求に頷くことでしょう。ActiveXは姿を消しましたが、その代わりとなった数多くのセキュリティプラグイン—AhnLab Safe Transaction、TouchEn nxKey、Veraportなど—は依然として私たちのPCへのインストールを要求しています。 TableCloth（食卓布）プロジェクトは、これらのセキュリティプログラムをWindows Sandboxという隔離された環境で実行できるようにするオープンソースツールです。TableClothカタログは、どの金融サイトでどのセキュリティプログラムが必要かを整理したデータベースの役割を果たしています。 今回のアップデート概要 TableClothカタログプロジェクトに5件のコミットが適用されました。今回のアップデートはフロントエンド、バックエンド、DevOpsの3つの領域にわたる総合的な改善です。 領域 変更内容 主要技術 フロントエンド カタログWebページの全面再設計 カードUI、カテゴリフィルター、レスポンシブレイアウト バックエンド ビルドツールアーキテクチャのリファクタリング Generic Host、依存性注入、構造化ロギング DevOps 品質管理自動化ツールの追加 画像検証、未使用リソース整理、ファビコン収集改善 各領域で何が変わったのか、なぜそのような決定を下したのか、詳しく見ていきます。 フロントエンド：テーブルからカードへ なぜUIを変更する必要があったのか？ 既存のカタログページは典型的なHTMLテーブル形式でした。カテゴリ、サービス名、必要なパッケージリストが行と列で整列された構造です。機能的には問題ありませんでしたが、いくつかの限界がありました。 まず、100を超えるサービスをスクロールしながら探す必要がありました。モバイル環境では横スクロールが発生してユーザビリティが低下し、視覚的な階層構造がないため情報の把握が困難でした。何より、カテゴリ別のフィルタリングができず、目的のサービスを素早く見つけることが難しい状況でした。 これらの問題を解決するため、カードベースのUIへの全面改編を決定しました。 XSLトランスフォームで実装したレスポンシブカードUI TableClothカタログの興味深い点は、データがXML形式で保存され、Webページが**XSLT（XSL Transformations）**を通じてレンダリングされることです。サーバーサイドのロジックなしに、ブラウザが直接XMLをHTMLに変換します。 デザイントークンシステムの導入 モダンなCSS設計の核心はデザイントークンです。色、間隔、影などをCSS変数として定義することで、一貫性のあるデザインを維持しながらメンテナンスが容易になります。 :root { /* カラーパレット */ --primary-color: #2563eb; --primary-hover: #1d4ed8; --bg-color: #f8fafc; --card-bg: #ffffff; --text-primary: #1e293b; --text-secondary: #64748b; --border-color: #e2e8f0; /* シャドウ */ --shadow: 0 1px 3px rgba(0,0,0,0.1), 0 1px 2px rgba(0,0,0,0.06); --shadow-lg: 0 10px 15px -3px rgba(0,0,0,0.1), 0 4px 6px -2px rgba(0,0,0,0.05); /* レイアウト */ --radius: 12px; } このカラースキームはTailwind CSSのデフォルトパレットからインスピレーションを得ています。スレート系のテキストカラーとブルー系のアクセントカラーを組み合わせることで、クリーンかつプロフェッショナルな印象を与えることができます。 ...

TableClothプロジェクトとは TableClothは、韓国のインターネットバンキング環境で必要なセキュリティプラグインをWindows Sandbox環境で安全に使用できるようにするオープンソースプロジェクトです。様々な金融機関のウェブサイトで要求されるセキュリティプログラムを隔離された環境で実行し、ホストシステムの安全を確保します。 カタログリポジトリとは TableClothCatalogリポジトリは、TableClothプロジェクトで参照する金融機関サイト別のセキュリティプログラムリストを保管する保存場所です。銀行、証券会社、保険会社などのウェブサイトで要求されるセキュリティプラグイン情報が体系的に整理されており、カタログビルダーツールはこの情報を基にTableClothアプリで使用可能な形式に加工します。 最近のカタログビルダーアップデート 最近、このリポジトリに重要なアップデートが適用されました。今回のコミットでは、カタログビルダーツールが.NET 10にアップグレードされ、プロジェクト構造が大幅に簡素化されました。 主な変更点 .NET 10アップグレード # 変更前 dotnet-version: 8.0.x # 変更後 dotnet-version: 10.0.x ビルドパイプラインが.NET 8から.NET 10にアップグレードされました。これにより、最新ランタイムのパフォーマンス向上と新しい言語機能を活用できるようになりました。 File-Based App（FBA）方式への移行 最も目立つ変化はプロジェクト構造の簡素化です。従来は別途の.csprojプロジェクトファイルとソリューションファイル（.sln）を使用していましたが、今回のアップデートでこれらのファイルが削除され、単一のC#スクリプトファイル（catalogutil.cs）に統合されました。 #!/usr/bin/env dotnet #:package [email protected] #:property PublishAot=false using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats.Png; using System.Collections.Concurrent; // ... これが.NETの**File-Based App（FBA）**方式です。FBAは以下のような利点を提供します： プロジェクトファイル不要：.csprojなしで単一の.csファイルでアプリケーション実行可能 インラインパッケージ参照：#:packageディレクティブでNuGetパッケージを直接参照 インラインビルドプロパティ設定：#:propertyディレクティブでビルドプロパティを設定 シバン（Shebang）サポート：#!/usr/bin/env dotnetでUnixスタイルの実行をサポート Graceful Shutdownサポート 新しいバージョンでは、プロセス終了時により安定した処理が可能になりました： // Graceful shutdown タイムアウト var gracefulShutdownTimeout = TimeSpan.FromSeconds(5); Console.CancelKeyPress += (sender, e) => { if (cts.IsCancellationRequested) { // 2回目のCtrl+C：強制終了 Console.Out.WriteLine("Info: Force exit requested. Terminating immediately..."); e.Cancel = false; return; } Console.Out.WriteLine($"Info: Cancellation requested. Shutting down gracefully (timeout: {gracefulShutdownTimeout.TotalSeconds}s)..."); Console.Out.WriteLine("Info: Press Ctrl+C again to force exit."); e.Cancel = true; // 即時終了を防止 cts.CancelAfter(gracefulShutdownTimeout); cts.Cancel(); }; 主な特徴： ...

サービス開発をしている同僚たちと話をしていると、AI導入について漠然とした負担感を感じているケースをよく見かけます。その負担感の根源を掘り下げると、大抵は**「学習（Training）」**という用語が生む誤解に起因しています。 「モデルをサービスに組み込むと、ユーザーデータを取り込んでリアルタイムで学習して賢くなるんですか？」 「じゃあ、その学習プロセスを私たちがコントロールできますか？変なことを学んだらどうしますか？」 もしこのような悩みをお持ちでしたら、少し心配を置いても大丈夫です。今日はその誤解を開発者の言葉で解説します。 「学習」はビルドタイム、「推論」はランタイム 最初に正すべきことは、私たちがサービスにデプロイするAIモデルは、ほとんどの場合「凍結された（Frozen）」状態であるという点です。 開発用語で例えると次のようになります。 概念 AI用語 開発用語の比喩 説明 モデルを作る 学習（Training） ビルドタイム（Build Time） 膨大なリソースと時間が必要 モデルを使う 推論（Inference） ランタイム（Runtime） リクエストを受けて結果を返す 私たちがサービスを運用するとき、実行中のバイナリコードが自らコードを修正して進化することはありません。AIも同様です。 モデルはデプロイされた瞬間、もはや「学ぶ学生」ではなく、**「指示通りに働く労働者」**になります。私たちが心配すべき領域は学習ではなく、この労働者がうまく仕事ができるよう環境を整えることです。 図書館の比喩でAI構造を理解する では、最新情報はどのように反映され、AIはどのような役割を果たすのでしょうか？私はこの構造を**「図書館」**に例えることがよくあります。 構成要素 図書館の比喩 説明 AIモデル（LLM） 司書 言語能力と推論能力を持つ存在 RAG / DB 書庫 サービスデータと最新情報が保存される空間 プロンプト 業務指示書 司書に仕事を任せるときに渡すガイドライン サービス開発者である私たちが毎日やっていることは、**「図書館に新刊を補充すること（DBアップデート）」**です。司書（AI）は私たちが補充した本を必要なときに取り出し（Retrieve）、内容を読んで組み合わせてユーザーに提供する（Inference）だけです。 多くの方が恐れている**「学習（Fine-tuning）」は、「司書を大学院に送って再教育すること」**に相当します。司書が基本的な読解力が不足している場合や、一般的な常識では理解できない特殊なドメインを扱う必要がある場合にのみ必要なエッジケースです。 ほとんどのビジネス問題は、司書を再教育（学習）させることではなく、以下の3つで解決できます： 優秀な司書を採用する - 良いベースモデルを選択 良い業務マニュアル - よく設計されたプロンプト 整理された書庫 - 構造化されたRAG/DB AIは「意味処理アクセラレータ」である このように構造を把握すると、AIはもはや恐ろしい未知の存在ではありません。単に私たちのシステムアーキテクチャに組み込むべき一つの**「部品」**に過ぎません。 コンピュータの歴史は「処理の高速化」でした。 ハードウェア 高速化対象 CPU 計算とロジック（if-else）処理 GPU グラフィックスとピクセル処理 AI（LLM） 意味（Semantics）と文脈（Context）処理 私たちはこれまでif (text.contains("りんご"))のようなコードで人間の言語を機械的に処理するのに苦労してきました。今では、その「意味処理」を専門に担当する高性能アクセラレータ（AI）が登場したのです。 おわりに AI時代だからといって、開発者がAIモデルを直接作ったり数式を理解したりしなければならないという強迫観念を持つ必要はありません。 MySQLの内部エンジンのソースコードを知らなくても優れたバックエンドサーバーを構築できるように、AIという**「優秀な司書」を私たちのサービスのどのデスクに座らせ、どのような権限を与えるかを設計するアーキテクチャリング能力**は今でも有効であり、さらに重要になっています。 AIに過度な意味を付与しないでください。それは自ら考えて反乱を起こす人工知能ではなく、私たちが入力したデータを確率的に最もそれらしく処理して返す**「関数（Function）」であり「ツール（Tool）」**です。 ツールは恐れるべき対象ではなく、手に馴染ませてうまく活用すべき対象です。

技術ブログを運営する上で最大の悩みは「どうすれば継続的に質の高い記事を書けるか」です。多言語でコンテンツを提供したいなら、翻訳まで気にしなければならないので、負担が倍増しますよね。 /dev/writeはこうした悩みから生まれました。Hugo静的サイトジェネレーターにGitHub Copilotを組み合わせて、執筆に集中できる環境を作ってみました。 なぜまたブログシステムなのか？ 正直に言えば、既存のブログプラットフォームも十分優れています。Medium、Qiita、Zenn、どれも素晴らしい選択肢です。でも、いくつか物足りない点がありました。 まず、多言語対応です。韓国語で書いた記事を英語と日本語でも提供したかったのですが、ほとんどのプラットフォームでは別アカウントや複雑な設定が必要でした。 次に、AI学習データとして使用されることへの懸念です。一生懸命書いた記事が同意なくAIモデルの学習に使われるのは、あまり気持ちの良いものではありませんよね。 そして、自動化されたワークフローです。記事を書いて、レビューして、翻訳して、公開するプロセスをできるだけ自動化したかったのです。 そこで、Hugo + PaperModテーマをベースに、この3つを解決するシステムを自作しました。 GitHub Copilotと一緒に執筆する /dev/writeで最も面白い部分は、GitHub Copilotを執筆ツールとして活用する方法です。VS Codeで/コマンドを入力すると、様々なプロンプトを呼び出せます。 /create-draft Dockerコンテナネットワーキングについて書いて こんな風にトピックだけ投げてもいいですし、もっと具体的にアウトラインを提供することもできます。 /create-draft - トピック：Kubernetes入門 - 内容：Pod、Service、Deploymentの概念 - 対象読者：Dockerを知っている開発者 既存のREADMEやドキュメントがあれば、それをベースにチュートリアルを作ってもらうこともできます。 /create-draft このREADMEファイルを基にチュートリアル投稿を作って #file:README.md AIが全部書くわけじゃない もちろん、AIに最初から最後まで任せることだけが答えではありません。むしろ自分でまず下書きを書いて、AIに肉付けしてもらう方式の方が良い結果を出すことが多いです。 例えば、以前別のブログで書いた記事を持ってきて技術ブログスタイルで書き直したい場合： /complete-manual-post この投稿を技術ブログスタイルで書き直して #file:my-old-post.md 自分で書いた下書きがあれば、コード例を追加したり説明を補強してもらうこともできます。 私が書いたこの下書きを基に、内容をより豊かにしてください。 コード例を追加し、説明をより詳しくしてください。 #file:2025-12-05-my-draft.md 個人的な経験や意見が重要な記事、技術的な正確性を自分で検証したい記事は、このアプローチの方がはるかに効果的です。AIはあくまで助手であり、最終判断は人間がするものですから。 1つ書けば3つできる /dev/writeのもう一つの特徴は自動翻訳です。韓国語で記事を書くと、英語と日本語バージョンが自動的に生成されます。 もちろん機械翻訳には限界があります。でも、最初から3言語で書くよりはずっとマシですよね。翻訳結果をレビューして、必要な部分だけ修正すればいいのです。 翻訳過程で一貫性を維持するために、いくつかのルールがあります。 slug、translationKey、dateなどのメタデータはすべての言語で同一に維持 タイトル、タグ、要約、本文は各言語に翻訳 コードブロックは翻訳しない（当然ですよね！） 英語はAmerican Englishで、日本語はです/ます体で作成されます。技術用語は原語を維持するか、括弧で併記します。 翻訳が終わったら、検証スクリプトで3言語バージョンがちゃんと揃っているか確認します。 .\scripts\validate-translations.ps1 技術ドキュメントの正確性検証 技術ブログで最も重要なのは正確性です。特にAzureや.NETなどMicrosoft技術を扱う時は、公式ドキュメントと一致するか確認するのが必須ですよね。 /dev/writeはMS Learn MCPサーバーを通じてこのプロセスを自動化しました。mcp.jsonファイルにMCPサーバーを登録して使用するように設定しています。 MCPサーバーがMicrosoft公式ドキュメントを照会して、最新APIバージョンか、非推奨の機能はないか、公式推奨事項と合っているかレビューしてくれます。ブログ記事に「この方法はもう推奨されていません」というコメントが付くのを事前に防げますよ。 ソーシャルメディアを意識した予約投稿 記事を書いたら公開しなければなりませんよね。/dev/writeは予約投稿をサポートしています。dateフィールドに未来の日付を設定すると、その時間に自動的に公開されます。 date: 2025-12-10T08:00:00+09:00 # 12月10日午前8時に公開 予約投稿はGitHub Actionsのcronトリガーで動作します。一日中動かすとランナーコストがもったいないので、ソーシャルメディアのピークタイムに合わせて1日3回実行するように設定しました。 午前8時：通勤中にスマホをチェックする時間 午後12時：昼休みにちょっとブラウジングする時間 午後5時：退勤前に最後にフィードをチェックする時間 schedule: - cron: '0 23 * * *' # KST 08:00 - cron: '0 3 * * *' # KST 12:00 - cron: '0 8 * * *' # KST 17:00 もっと細かい公開スケジュールが必要な場合は、ローカル環境で直接トリガーを設定することもできます。Windowsタスクスケジューラやcrontabを活用すれば、1時間間隔、30分間隔など、好きなように調整可能です。GitHub Actionsの無料枠も節約でき、公開タイミングもより精密に設定できますよ。 ...

はじめに Windows Proには標準でHyper-Vが含まれています。別途仮想化ソフトウェアをインストールしなくても、OS内で直接仮想マシンを作成・管理できます。この記事では、Hyper-Vの第2世代（Generation 2）仮想マシンを使用してUbuntuを起動する方法をご紹介します。 まず、管理者権限でPowerShellを開き、次のコマンドを入力してHyper-V機能を有効にします。 Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All インストールが完了したら、システムを再起動してください。 次に「Hyper-Vマネージャー」を起動し、新しい仮想マシンを作成します。世代は必ず「第2世代（Generation 2）」を選択し、メモリは4GB以上、ディスクは20GB以上を指定してください。 ネットワークアダプターは「既定のスイッチ（Default Switch）」を選択すれば、追加設定なしですぐにインターネット接続が可能です。 次に、Ubuntu公式サイトからISOイメージをダウンロードし、仮想マシンのDVDドライブ→「イメージファイル」に接続します。ファームウェア設定でDVDドライブを起動順序の一番上に移動させれば、ISOから直接起動できます。 重要なポイント ここまでは一般的な手順です。しかし、実際にUbuntuをインストールしようとすると、「No bootable device」や「Start boot option」などのエラーが発生し、起動できないことがよくあります。 その理由は簡単です。Hyper-Vの第2世代VMは、デフォルトでWindows専用のUEFIセキュアブートテンプレートを使用しているからです。 この問題を解決するには、仮想マシンを作成した後、必ず「設定→セキュリティ」に移動してください。 ここで**「セキュアブートを有効にする（Enable Secure Boot）」にチェックを入れ、下の「テンプレート」オプションを「Microsoft UEFI証明機関（Microsoft UEFI Certificate Authority）」**に変更してください。 この設定が正しく行われていないと、Ubuntuのブートローダーが署名されていないイメージとして認識され、UEFIによって起動がブロックされます。 つまり、ISOファイルやディスク構成をいくら作り直しても、この設定がなければUbuntuは絶対に起動しません。 上記の手順を完了すると、Ubuntuのインストール画面が正常に表示され、案内に従ってインストールを進めることができます。 Ubuntu 20.04以降のバージョンには、Hyper-V統合サービスがデフォルトで含まれているため、追加のドライバーをインストールしなくても、クリップボード共有、画面解像度の自動調整、時刻同期などの機能がすぐに動作します。 結論として、Hyper-V第2世代VMでUbuntuを起動するには、「セキュアブートテンプレート」を必ずMicrosoft UEFI証明機関に設定する必要があります。 この1つの設定さえ忘れなければ、Windows Pro環境でも安定してUbuntuを実行し、開発環境を構築することができます。