開発者向け

APIが用意されていないサービスは選択肢から真っ先に除外しましょう この記事の内容 計算量（オーダー）の考え方を、ソフトウェアだけでなく業務運用にも適用すべきという話です 顧客数やコンテンツ数が増えると、手作業の運用は O(n²) 的に破綻することがあります 「とりあえず動けばいい」で最初の仕組みを作ると、後から運用する人が苦労します APIがあるサービスを選ぶことで自動化が可能になり、スケール問題を回避できます サービス・プロダクトを選定する際は、APIの有無を最初の判断基準にしましょう 計算量（オーダー）の話 今回は少し雑談ベースでお伝えします。話したいテーマは大きく2つあります。1つ目は作業や計算のオーダー（計算量）を考えましょうという話、2つ目はAPIを持っているサービスやプロダクトを必ず選択しましょうという話です。 どちらも当たり前すぎる話ではあるのですが、目の前の「とりあえず最初の一歩」だけを考えて「うまく動いているからこれでいいじゃん」となりがちな部分があるため、改めてお伝えしたいと思います。 まず、計算量やオーダーについての話です。ソフトウェアのアルゴリズムを勉強した方なら常識かと思いますが、愚直に処理を書いてしまうと計算量が O(n²) のオーダーになってしまうことがあります。 グラフで示すと、O(n)（線形） の場合は数が増えてもそれに比例してゆるやかに増加していきます。一方で O(n²)（二乗） の場合は、小さいうちはほとんど問題ありませんが、数が増えるにつれてあっという間に計算量が爆発的に増え、処理時間が膨大になっていきます。 ソフトウェア開発においては「良いアルゴリズムを選ぶ」「高速なアルゴリズムを採用する」というのが常識ですが、この考え方は普段のシステム設計や業務運用にも同じように当てはまります。 業務運用における「オーダー」の問題 わかりやすい例として、人間が手作業で運用をカバーするケースを考えてみましょう。 スケールしやすいケース（O(n) に近い） お客さんが1件増えるたびに決まった作業を1回だけ実施して、それで完結する場合、お客さんの数が増えてもその分だけ同じ作業をすればよいだけです。これはいわば O(n) のイメージ で、そこまで破綻しません。 スケールしにくいケース（O(n²) に近い） 一方で、次のような状況を考えてみましょう。 顧客数が増えると、既存のすべての顧客にも追加の作業が発生する コンテンツが更新されるたびに、すべての顧客にそのコンテンツを配布しなければならない 顧客数もコンテンツ数も両方増えていく このような場合、コンテンツを1つ更新するだけで「全顧客 × 全コンテンツ」の展開作業が必要になります。これは O(n²) 的に作業量が増えていく構造 です。 最初は顧客が1〜2件、10件程度であれば全く問題ありません。しかし50件になり、100件になると、手作業の量はものすごい勢いで積み上がっていきます。 「とりあえず動けばいい」が後から苦労を生む こうした状況は、最初に仕組みを作る人が、後で運用する人のことを考えないことで生まれがちです。 「とりあえずこれで動いているからいいでしょ」という状態で最初の仕組みを作ってしまい、その後どう変化していくか、数がどう変わっていくかを考慮しないまま設計してしまうのです。その結果、何年もその仕組みを使い続ける運用担当者が苦労することになります。 月次レポートの作成なども典型例です。管理するシステム数が増えるたびに作成するレポートの数が増え、さらにカスタマイズ要件が入ってきたらすべてのシステムに対してその変更を適用しなければならない——こうした状況が積み重なっていきます。 解決策はAPIのあるサービスを選ぶこと では、どうすればいいか。結論はAPIがあるものを使いましょうということです。 APIがあるということは、自動化ができるということです。人間が手作業でやっている作業は、APIがあればすべてプログラムに置き換えることができます。 逆に言えば、APIがないと人間がすべてを手作業でやることしかできません。 手作業を自動化しようとすれば、RPAのような話になってきます。RPAで自動化すること自体を否定するわけではありませんが、APIがある場合に比べて汎用性や安定性に課題が出てくることが多いです。 サービス選定時にAPIの有無を最初に確認すべき理由 サービスやプロダクトを選定する際、機能の豊富さや画面の使いやすさに目が向きがちです。しかし、APIが用意されているかどうかは最も最初に確認すべき条件の一つです。 APIがないサービスは、業務が拡大するにつれて必ず運用の壁にぶつかります。最初は小さな規模だから問題なく回っていたとしても、顧客数やデータ量が増えた瞬間に手作業の工数が爆発的に増え、人員を増やすか、仕組みを作り直すかという選択を迫られることになります。 そうした将来的なコストを避けるためにも、APIが用意されていないサービスは選択肢から真っ先に除外するという判断基準を持つことが大切です。 まとめ 計算量（オーダー）の考え方は業務運用にも当てはまります。 O(n²) 的に作業が増える仕組みは、規模が小さいうちは問題なくても、成長とともに必ず破綻します。 最初の設計が後から運用する人の苦労を決めます。 「とりあえず動けばいい」で作られた仕組みは、長期的に大きな負債になります。 APIがあるサービスを選ぶことで自動化が可能になり、スケールの問題を根本から解決できます。 サービス・プロダクトを選定する際は、APIの有無を最初の判断基準に置くようにしましょう。APIがないサービスは、原則として選択肢から外すくらいの意識が重要です。

ObsidianにあれこれとSNS活動記録を自動収集する仕組みを作る この記事の内容 YouTubeやはてなブックマークの活動記録をObsidianデイリーノートへ自動集約するアーキテクチャを解説 X（旧Twitter）APIの有料化という壁と、Blueskyをハブにした代替アーキテクチャの検討 Obsidianプラグイン・iPaaS・自作スクリプトの3つの実装方針を比較 日次バッチ＋常駐クロスポストの2スクリプト構成による実装方針を紹介 自分のデータを一元管理することで、将来的なAI活用に備える考え方を共有 なぜ情報を自動収集するのか Obsidianには日々のタスクや思考をまとめるデイリーノートがあります。ここに、YouTubeへの動画投稿、はてなブックマークへの登録、X（旧Twitter）へのポストなど、様々なプラットフォームでの活動記録を自動で集約できたら——そんな仕組みを構築しています。 Kindleのハイライトが自動同期されるように、自分の活動が半自動的にObsidianへ記録され、一元管理できる状態が理想です。散在しがちな情報を一箇所にまとめることで、将来的に知識として活用できると期待しています。 すでに実現できていること いくつかの連携は、Pythonスクリプトを書いてすでに実現しています。 YouTube連携 動画を投稿すると、YouTube API経由でURLや文字起こしデータを取得し、Obsidian内に自動でノートを作成します。さらに、その日のデイリーノートにリンクを追記する処理も組み込んでいます。LLMを使って文字起こしをブログ形式に整形・要約させる処理も含まれており、非常にうまく機能しています。 はてなブックマーク連携 その日にブックマークした記事の情報を取得し、同様にObsidianノートとして保存する仕組みも完成しています。 これらの仕組みにより、活動の一部は着実にObsidianへ蓄積されるようになっています。 最大の課題：X（旧Twitter）との連携 大きな壁として立ちはだかっているのが、X（旧Twitter）との連携です。 2007年から十数年続けているXへの投稿も、ぜひObsidianに記録したいと考えていました。しかし、現在のX APIは仕様が変更されており、自分の投稿データを取得するだけでも月額100ドル（約15,000円）ほどの高額な有料プランへの加入が必須となっています。 個人のつぶやきを記録するためだけにこのコストを支払うのは現実的ではありません。かつてのTwitter時代には無料で自由にできていたことが、今は非常に困難になってしまいました。 解決策：Blueskyを新たなハブにする Xでの直接連携を諦め、代替案として検討したのが「Bluesky」をハブとして利用する方法です。BlueskyはAPIが公開されており、データ連携が比較的容易です。 考えたアーキテクチャは以下の通りです。 投稿: PCやスマートフォンのアプリから、まずBlueskyに投稿する 記録: Blueskyへの投稿をトリガーに、API経由でその内容を取得し、Obsidianのデイリーノートへ自動記録する クロスポスト: 同時に、Blueskyへの投稿をX・Mastodon・Discordなどへ自動転送（クロスポスト）する この仕組みが実現すれば、Blueskyに一度投稿するだけで、Obsidianへの記録と他SNSへの展開がすべて自動で行われるようになります。 実装方針の比較検討 このアーキテクチャを実現する方法として、3つの選択肢を検討しました。 方法 メリット デメリット Obsidianプラグイン Obsidian内で完結 アプリを開いている時しか動作しない iPaaS（Zapierなど） 手軽に構築できる 外部サービス依存・追加コストの懸念 自作スクリプト 柔軟性が高く既存環境を活用できる 開発の手間がかかる リアルタイム性は必須ではなく、1日1回まとめて記録できれば十分と判断し、自作スクリプトで構築することに決めました。常時稼働中のVMがすでにあるため、追加コストも発生しません。 実装する2つのスクリプト 自作スクリプトの構成として、以下の2つを作成します。 1. 日次バッチスクリプト 1日1回、その日のBluesky全投稿を取得し、Obsidianのデイリーノートに書き込みます。既存の日次処理の仕組みに組み込む形で実装します。 [ B l u e s k y A P I ] → ( 日 次 バ ッ チ ) → [ O b s i d i a n デ イ リ ー ノ ー ト ] 2. 常駐クロスポストスクリプト 常時稼働しているVM上で動作し、Blueskyの新規投稿を監視します。投稿があれば即座にXなどへ転送します。 ...

Azure CLIとAzure PowerShellのBuild 2025でのアナウンス事項 この記事の内容 Microsoft Build 2025でAzure CLIがLTS（長期サポート）に対応することが発表されました Azure PowerShellではGet-AzAccessTokenがSecureStringを必須で返すように変更されました（破壊的変更） Microsoft Artifact Registry経由でのインストールが推奨方式になります リアルタイムプログレスバーや動的アウトプット表示など、ユーザーエクスペリエンスが向上します CopilotへのRAG導入によって、より正確な回答が得られるようになります はじめに Microsoft Build 2025において、Azure CLIおよびAzure PowerShellに関する最新のアナウンスがありました。今回の発表では革命的な新機能の追加というよりも、主に品質・セキュリティ・ユーザーエクスペリエンスの向上、そしてCopilotの応答性能改善に焦点が当てられています。 Azure CLIとAzure PowerShellのLTS対応 Azure PowerShellでは2024年11月にStandard-Term Support（STS）とLong-Term Support（LTS）の両方に対応することが発表されていましたが、Build 2025ではついにAzure CLIもSTSおよびLTSをサポートすることが発表されました。 LTS（Long-Term Support）: 12ヶ月間のサポートが提供されます。特定バージョンを長期間安定して使い続けたい組織に適しています STS（Standard-Term Support）: 最新機能が随時提供されますが、バージョンアップが頻繁に発生します これまでAzure CLIは更新が頻繁であったため、特定のバージョンで動作が変わることがありました。LTSの導入により、Azure DevOpsやGitHub ActionsなどのCI/CDパイプラインでより安定した運用を選択できるようになります。 Azure PowerShellにおけるSecureStringの利用拡大 PowerShellの世界では、機密情報を安全に扱うためにSecureString型が利用されます。Azure PowerShellでもSecureStringの採用範囲が拡大されています。 Get-AzAccessTokenの変更（破壊的変更） Get-AzAccessTokenコマンドレットの返り値が変更されました。 変更前: オプトインでSecureStringを返すことができた 変更後: SecureStringが必須（デフォルト）になった この変更により、アクセストークンが生の文字列としてコンソールに表示されなくなります。ただし、**これは破壊的変更（Breaking Change）**です。アクセストークンを直接文字列として扱っていた既存のスクリプトは修正が必要になりますのでご注意ください。 また、2026年に向けて、キーやトークンを返すその他の多くのコマンドレットも順次SecureStringを返すように変更される予定です。 Microsoft Artifact Registry経由でのインストール 今後のAzure PowerShellのインストールでは、Microsoft Artifact Registry（ACR）を利用する方法が推奨方式となります。これにより、より安全にモジュールをインストールできるようになります。 具体的なインストール手順は以下の通りです。 # Microsoft Artifact Registryをリポジトリとして登録 Register-PSResourceRepository -Name "MS-PSGallery" -Uri "https://psg-prod-eastus.azureedge.net/api/v2/" # Azure PowerShellのインストール Install-PSResource -Name "Az" -Repository "MS-PSGallery" ユーザーエクスペリエンスの向上 コマンドラインツールとしての使いやすさを向上させるための改善も発表されました。 ...

net useとNew-SmbGlobalMappingでは挙動が違う！という話 この記事の内容 Windowsのドライブマッピングには net use と New-SmbGlobalMapping の2種類のアプローチがある net use は実行したユーザーのセッション内でのみ有効で、他ユーザーやシステムサービスからはアクセスできない New-SmbGlobalMapping はシステム全体（グローバル）でのマッピングを作成し、全ユーザー・全プロセスから利用できる Azure VMとAzure Filesの組み合わせなど、常時マウントが必要な共有ストレージには New-SmbGlobalMapping が適している エクスプローラーへの表示タイミングにも違いがあり、実際の挙動を把握することが重要 はじめに：2つのドライブマッピング手段 Windowsでネットワーク上のファイル共有をローカルドライブのように扱う「ドライブマッピング」は、多くの管理者や開発者にとって馴染み深い機能です。古くから使われている net use コマンドが一般的ですが、特定のシナリオにおいてその挙動の違いで混乱することがあります。 たとえば、「ユーザーAでマッピングしたドライブが、ユーザーBやシステムアカウントからアクセスできない」といった問題がその典型です。これは net use コマンドの仕様に起因するものであり、この問題を解決するために New-SmbGlobalMapping というコマンドレットが存在します。 本記事では、net use と New-SmbGlobalMapping の具体的な違いと、それぞれのコマンドがどのようなコンテキストで動作するのかを、実際の動作を交えて詳しく解説します。 net useコマンドの挙動と限界 net use は、Windowsでドライブマッピングを行うための伝統的なコマンドです。特定のドライブレター（例：Z:）にファイル共有のパスを割り当てることで、ユーザーはエクスプローラーなどから簡単にアクセスできるようになります。 # net use の基本的な構文例 net use Z: \\サーバー名\共有名 /user:ユーザー名 パスワード /persistent:yes このコマンドの重要な特徴は、実行したユーザーのセッション内でのみ有効であるという点です。ログオンスクリプトなどで特定のユーザーのためにドライブを割り当てる場合には非常に便利ですが、以下のような制約があります。 他ユーザーからアクセスできない： あるユーザーが net use でマッピングしたドライブは、他のユーザーアカウントからは見えず、アクセスもできません システムサービスから利用できない： Windowsサービスなど、システムアカウント権限で動作するプロセスからは、ユーザーがマッピングしたドライブを利用することができません 「そのユーザーがログインしている間だけ使えれば良い」という用途には適していますが、サーバー上で永続的かつグローバルに利用したい場合には不向きです。 New-SmbGlobalMappingによるシステムワイドなマッピング net use の課題を解決するために登場したのが、PowerShellの New-SmbGlobalMapping コマンドレットです。このコマンドはWindows Server 2019以降などの比較的新しいOSで利用できます。 # New-SmbGlobalMapping の基本的な構文例 $creds = New-Object -TypeName System.Management.Automation.PSCredential ` -argumentlist "ユーザー名", (ConvertTo-SecureString "パスワード" -AsPlainText -Force) New-SmbGlobalMapping ` -RemotePath \\サーバー名\共有名 ` -LocalPath X: ` -Credential $creds ` -Persistent $true 名前が示す通り、このコマンドはグローバルな（システムワイドな）マッピングを作成します。主な特徴は以下の通りです。 ...