はじめに 仕事では「言われたことをそのまま実行したのに怒られる」という理不尽な出来事が起こることがあります。 この記事では、曖昧な指示や、認識の違い、記憶違いによる職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「自分が言ったことを5分で忘れる理不尽上司」 これは関東のとあるシステム開発会社での出来事。 複数のプロジェクトが同時に動くオフィスでは、サーバー構築やシステム開発、データ分析などの業務が日常的に行われていた。 社員たちはそれぞれの案件を抱え、部署やプロジェクトの垣根を越えて協力する場面も多かった。 ある日、オフィスレイアウト変更に伴い、別プロジェクトの上司Bが、別フロアに異動となり、デスクを移動することになった。 部下Aは自分の担当業務を進めている最中、突然電話を受ける。 上司B 😐 「これからデスクを移動するから、私の机の上にある物を全部机から片付けてまとめておいて。」 部下A 🙂 「わかりました。」 上司Bの机に目をやると、デスクトップ型PCが設置されていたからだ。 念のため確認した方がいいと考えた部下Aは、再度連絡を入れた。 部下A 🤔 「机の上にデスクトップPCがありますが、これも片付けてよろしいでしょうか？」 上司B 😐 「いいよ。全部片付けておいて。」 部下A 😊 「承知しました。」 確認も取れたため、部下Aは安心して片付けを始めた。 書類、文房具、小物類を整理し、段ボールにまとめる。 最後にPCへ手を伸ばす。 するとPCの電源ランプが点灯していることに気付いた。 部下A 🤔 「あれ、電源が入っているな。」 しかし、机から移動するには電源を切るしかない。 しかも先ほど「PCも片付けてよい」と明確に許可を得ている。 デスクから下すにためには、当然電源も切る必要がある。 そう判断した部下Aは、通常の手順でシャットダウンを実施し、PCを片付けた。 数分後。 オフィスの空気が突然変わった。 上司B 😠 「誰だ！！PCの電源を切ったのは！！」 周囲の社員たちが驚いて顔を上げる。 部下A 😳 「私です。片付けるよう指示をいただいたので……。」 上司B 😡 「勝手に人のPCの電源を切ったらだめだろ！！」 部下A 😨 「???」 どうやら上司BはPC上で大規模な計算処理を実行していたらしい。 その処理は長時間かかる作業で、電源を切られたことで途中で停止してしまったのだ。 部下A 😰 （いや、だから確認したんだけど……。） しかし上司Bの怒りは収まらなかった。

はじめに この記事では、フリーランスITエンジニア向け案件紹介サービスギークスジョブについて解説します。 岡山県など地方在住者におすすめできるかも含めて、メリット・デメリットを整理しました。 ギークスジョブとは ギークスジョブは、ITフリーランスエンジニア向けの案件紹介エージェントサービスです。 運営はギークス株式会社です。 ギークスジョブは最大手のレバテックフリーランスにつぐ、大手のエージェントで、多数の案件数やサポート体制を特徴としています。 高単価・長期案件を中心に、Web／業務系／インフラなど幅広い技術領域の案件を取り扱っています。 専任コンサルタントがキャリア相談、案件提案、単価交渉、参画後フォローまで一貫してサポートする点が特徴です。 特に実務経験2年以上のエンジニア向けの案件が多く、エンド直請けや大手企業案件も豊富です。 ギークスジョブ公式サイト .btn-wrapper { max-width: 600px; margin: 0 auto; padding: 20px 0; } .pink-btn { display: block; width: 90%; background: linear-gradient(#ff77bb, #ff4fa0); color: #fff; padding: 18px 0; border-radius: 8px; text-decoration: none; font-weight: bold; font-size: 18px; text-align: center; box-sizing: border-box; box-shadow: 0 4px 0 #d6458a, 0 6px 12px rgba(0,0,0,0.2); transition: all 0.2s ease; } .pink-btn:active { transform: translateY(3px); box-shadow: 0 1px 0 #d6458a, 0 3px 6px rgba(0,0,0,0.

はじめに 目標管理制度を初めて導入する会社では、思わぬところでつまずくことがあります。 今回は、目標設定そのものに膨大な時間がかかってしまい、肝心の業務改善に手が回らなくなってしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「目標設定に四半期の約1/4を消費する会社」 これは設立30年以上の中小SIerでの出来事。 これまで目標管理の仕組みが存在しなかったこの会社で、経営層の意気込みのもと、初めて全社員による個人目標設定が導入されることになった。 現場を統括する課長Hが自身のチームの目標を作成し、役員Fへの説明の場に持ち込んだ。 課長H 🙂 「今期のチーム目標は『担当システムの保守品質を向上させる』としました。」 役員F 😐 「そんな目標じゃ、ぬるい。もっと危機感を持って考えろ。」 課長H 😳 「危機感……ですか。具体的にはどのあたりを……」 役員F 😠 「そんなことまで俺が説明しなきゃいけないのか！お前がチームの責任者だろう！！」 課長Hは何が悪かったのか具体的な説明を得られないまま、感情論だけで目標を突き返された。 しかし部下への説明の場では、役員から言われたことを何とか自分の言葉に変換しようとする。 課長H 😓 （役員は「危機感」とか「ぬるい」って言ってたな……つまり、もっと厳しくすればいいのか？） 課長H 🙂 「みんな、今期の目標だけど、もっと危機感を持って厳しめに設定しよう。」 部下G 🤔 「危機感、というのは具体的にどういう……」 課長H 😅 「いや、そこはお前らで考えてくれ。とにかく緩い目標はダメだって話だから。」 部下Gたちは意図のつかめないまま、とりあえず数値を厳しくした目標を作り直し、再び課長Hを経由して役員Fへ持ち込む。 課長H 🙂 「危機感を持たせた目標に修正しました。」 役員F 😡 「なんだこれ、数字だけ厳しくすればいいってもんじゃないだろ！！本質を考えろと言ったはずだ！！」 課長H 😨 「す、すみません……」 課長Hはまた役員から罵声を浴びるが、「本質」という言葉の意味も具体的にはつかめないまま部下の元へ戻る。 課長H 😰 「役員から、本質を考えろって言われたんだ。もう一度、本質的に考え直してくれ。」 部下G 😔 「本質……というのは、前回の『危機感』とは違う話ですか？」 課長H 😩 「いや……それは……とにかく、もっと深く考えてくれ。」 部下Gたちは、前回の指摘との関係もわからないまま、また目標を修正する。 このやり取りが何度も繰り返され、目標は一向に固まらなかった。 部下G 😩 （もう4回目の書き直しだ……何を直せばいいのか、誰にもわかっていない。） 課長H 😥 （役員が何を言いたいのか、自分にも正直よくわかっていない……。） 気づけば、目標設定だけで3ヶ月以上が経過していた。

はじめに この記事では、フリーランスITエンジニア向け案件紹介サービスPE-BANKについて解説します。 岡山県など地方在住者におすすめできるかも含めて、メリット・デメリットを整理しました。 PE-BANKとは PE-BANKは、ITエンジニア専門の案件紹介サービスです。 1989年創業の老舗で、エンジニア主体の共同受注モデルを採用しています。 共同受注モデルなので、契約内容に透明性があり、マージン率が公開されているため、良心的なフリーランスエージェントと言われています。 運営会社: 「株式会社PE-BANK」 PE-BANKの運営会社は株式会社PE-BANKです。 同社は、フリーランスITエンジニア向けの共同受注事業を中心に展開する企業で、1989年創業の実績ある会社です。 項目 内容 会社名 株式会社PE-BANK 設立 1989年 所在地 東京都港区高輪2-15-8 グレイスビル泉岳寺前 事業内容 ITエンジニア共同受注事業 上場 非上場 長年にわたりエンジニア主体のビジネスモデルを継続しており、全国に拠点を展開している点が特徴です。 PE-BANKの特徴 項目 内容 対応エリア 全国（主要都市に拠点あり） リモート案件 一部あり（常駐案件が中心） 案件数 非公開（全国で常時多数） 平均月単価 60万〜80万円前後 消費税表記 税抜き表示が基本 マージン率 公開制（参画期間が長いとその分マージン率が下がる仕組み、10～15％前後） 福利厚生 共済会制度あり（保険・税務サポート等） 特徴 高還元率とマージン公開の透明性が強み PE-BANKは、1989年創業の老舗フリーランスエージェントです。 エンジニア主体の「共同受注」モデルを採用し、報酬還元率の高さと透明性を重視しています。

はじめに 「なぜ中小企業ではスキルが伸びないのか」—— 転職や異動を経験した人なら、この疑問を感じたことがあるかもしれません。 大企業と比べて研修制度が整っていない、という指摘はよくあります。しかしそれだけではなく、組織文化や個人の習慣レベルに深い根本原因が存在します。 表面的な「研修がない」「予算がない」という理由の背後には、目標設定能力の欠如、学習に対する姿勢の問題、そして日常的な生活習慣まで、複合的な要因が絡み合っています。これらは一朝一夕には解決できず、組織全体の文化として根付いているケースがほとんどです。 本記事では、実際の現場で起きた事例をもとに、中小企業でスキルアップが進まないの理由を解説します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 1. 目標設定と達成プロセスが機能しない 中小企業だとメンバーの論理的思考力や語彙力に長けた社員が少ないため、目標設定自体ができないケースが多々あります。 以下の例では、目標設定メソッドにマンダラチャートを採用しましたが、社員のスキルの低さから、目標設定ができずに終わってしまったようです。 本当にあった?エンジニアの怖い話「マンダラチャートで目標すら立てられない会社のPDCA」 —— 論理的思考力の弱さから目標設定そのものが機能しなかった事例 目標を立てる能力が弱い組織では、スキル向上の仕組みそのものが成立しません。 論理的思考力がなければ「何を・いつまでに・どうやって」という構造で考えられないため、計画は絵に描いた餅になります。 目標を設定すること自体にもスキルが必要で、適切な目標設定をできない組織にいる限り、成長は難しいのではないかと思います。 目標設定に時間がかかり過ぎる 本当にあった?エンジニアの怖い話「目標設定に四半期の約1/4を消費する会社」 —— 目標設定の仕組みが整っておらず、議論だけで大量の時間を消費した事例 目標設定のノウハウが組織に蓄積されていないと、毎回ゼロから議論を始めることになり、肝心の実行期間そのものが削られてしまいます。 さらに厄介なのは、「時間をかけた＝真剣に取り組んだ」という誤った達成感で終わってしまい、プロセス自体の非効率さが問題として認識されにくい点です。 目標設定に時間がかかること自体は個人の努力不足ではなく、仕組みが整っていない組織のサインであり、そうした環境ではスキルアップに使うべき時間がそもそも確保できません。 自分本位の考えを重視し、教科書通りの学習をしない 本当にあった?エンジニアの怖い話「勤怠ソフトのボタンをてんとう虫にする会社」 「経験」や「勘」に頼って仕事を進める文化では、教科書的な手法が「理屈っぽい」「現場をわかっていない」と軽視されがちです。 しかしこの文化のもとでは正しい方法論を学ぶ動機自体が生まれず、再現性のあるスキルが身につきません。 感覚的な判断は個人の経験に強く依存するため、他のメンバーへの知識移転もできず、組織として学習が積み上がっていかないのです。 技術への興味が薄く、知識が広がらない 事例 これは、複数の物理サーバーを管理するプロジェクトの事例です。 あるプロジェクトで、複数のサーバーに対して同時にコマンドを実行できるSSHクライアント「Rlogin」を選定・採用しました。 このRloginを使うことで、同じ作業を各サーバーに個別に実施する手間が大幅に削減でき、ヒューマンエラーのリスクも低減できます。 導入した担当者は事前に動作検証を行い、Rloginがプロジェクトの要件にも合致していることを確認した上での採用でした。 ところが、このツールをプロジェクトで展開しようとしたとき、ベテラン社員から思わぬ反発を受けました。 「Teraterm以外のツールは聞いたことがない。有名なツールではない。」 という理由だけで、「基礎を無視したやり方だ」「なぜ実績のあるツールを使わないのか」と担当者に対して批判的な意見が述べられました。 ツールの選定基準として本来評価すべきは、プロジェクトとの適合性のはずです。　しかし実際には、「自分が知っているかどうか」が唯一の判断基準になっていました。 結果として、このツールの採用は見送られ、効率の悪い従来の手作業が継続されました。 理由 ツールの知名度や自分の馴染みで技術を評価する文化が存在すると、合理的な判断ができなくなります。 この姿勢の根本には、技術への好奇心の欠如があります。 「知らないものは怖い」「今のやり方で困っていない」という意識が強いと、新しい技術や手法を積極的に学ぼうとする動機が生まれません。その結果、知識が特定の範囲に固定されたまま広がらず、技術の進化に取り残されていきます。 また、このような文化では新しい提案をした人が「基礎がわかっていない」と逆に批判されるため、若手エンジニアの学習意欲を削ぐ効果もあります。 知識を広げようとする行動がリスクになる組織では、現状維持が最も合理的な選択になってしまいます。 2. 学習を阻害する生活習慣 事例 これは、特定の1社ではなく、複数の中小企業で共通して見られた傾向をまとめた事例です。 スキルアップには継続的な努力が必要です。しかし、日常の生活習慣がその継続を根本から阻害しているケースが少なくありません。 具体的には、 業務後にパチンコや競馬などのギャンブルを日課にしている 喫煙の頻度が非常に高く、就業中も離席が多い 飲酒量が多く、翌朝に疲労が残った状態で出勤する スマートフォンのSNSやゲームに長時間費やしている といった習慣を持つ人が、複数の中小企業の現場で一定数見られました。 こうした習慣が日常化している人ほど、 資格の勉強を始めても数日で挫折する 「勉強しようと思っていたが、気づいたら夜になっていた」を繰り返す 仕事中の集中力が続かず、同じ作業に時間がかかる という傾向が見られ、長期的なスキル形成に至りませんでした。

はじめに エンジニアのキャリアを考えるとき、「東京に行けばもっと最新技術に触れられる」「地方にいては技術力が遅れてしまう」と考える方は多いのではないでしょうか。 確かに東京には多くのIT企業が集中しており、案件数も豊富で最新技術が採用されやすい環境があります。 しかし、東京に上京したからといって、必ずしも最新技術を習得できるわけではありません。 この記事では、東京と地方のエンジニア環境を比較しながら、上京を検討しているエンジニアが知っておくべき現実について解説します。 東京のメリット 案件数・技術スタックの多様性 東京にはIT企業が数多く存在し、案件数も地方と比べてはるかに多く、プロジェクトで採用される技術スタックも比較的新しいものが採用される傾向があります。 最新のクラウド技術やモダンなフロントエンドフレームワーク、AIを活用したシステム開発など、先進的な取り組みをしている企業も多く存在します。 東京のデメリット 案件数が多い分、「案件ガチャ」がある 日本国内の企業のほとんどは中小企業です。案件数が多いがゆえに、以下のようなケースにアサインされるリスクも存在します。 マイナーな技術を採用したプロジェクト: 需要が限定的で、転職市場での汎用性が低い技術を使い続けることになる システム開発と関連性が低い作業: 運用監視や単純なデータ入力など、エンジニアとしての成長につながりにくい業務 レガシーシステムの保守: 最新技術とはかけ離れた古いシステムの維持管理 人間関係の課題: プロジェクトのステークホルダーとのコミュニケーションがうまくいかなかったり、メンバーの技術スキルが低く、レビューやサポートに想定以上の工数を取られる いわゆる 「案件ガチャ」 と呼ばれる状況があり、良い案件に当たればスキルアップのチャンスになりますが、そうでない場合のリスクも無視できません。 上京してもスキルアップできる保証はなく、運次第という側面があるのが現実です。 地方のメリット 使用技術の汎用性 地方で仕事をする場合でも、技術スタック自体は必ずしも時代遅れではありません。 マイナーな技術ではなく、業界で広く使われているメジャーな技術を用いた開発が多いため、習得したスキルが汎用的に活かせるケースが少なくありません。 昔からあるJava、C#など需要の高いプログラミング言語 AWS、Azureなど広く普及しているクラウドサービス SQL Serverやpostgrresqlなど標準的なデータベース 取引先は都市部の企業 地方に拠点を置いていても、実際の取引先はほぼ東京・大阪などの都市部の企業になることが多いです。 地方に就職したからといって、仕事内容が大きく変わるわけではありません。 リモートワークやオンライン会議の普及により、物理的な距離のハンデはかつてより小さくなっています。 生活コストが安い 地方と東京では生活コストに大きな差があります。 項目 東京 地方（岡山など） 家賃（1K） 8〜12万円 4〜6万円 駐車場代 2〜5万円 3,000〜5,000円 物価全般 高い 比較的安い 年間で50万円以上の差が出ることも珍しくありません。

はじめに この記事では、 AIコーディングエージェント向けのタスク管理ツール「Beads (bd)」を紹介します。 Claude Codeなどのエージェントにタスクを記憶させ、セッションをまたいだ作業管理を可能にするツールです。 beadsとは AIエージェントが使用することを前提に作られたタスク管理ツールです。 bdコマンドというCLIを使ってタスク管理ができます。 CLIでタスクを操作できることから、Claude Codeなどのバイブコーティングツールを使用する開発者から高評価を得ています。 GitHub - gastownhall/beads: Beads - A memory upgrade for your coding agent GitHub Issueなどとの違い プロジェクトのタスク管理というとGitHub Issueが古くから使われていますが、GitHub Issueとbeadsのメカニズムの違いや、beadsを使うメリットは以下の通りです。 依存関係の設定ができる このタスクを完了しないと次のタスクを実行できない、といった複雑な依存関係の設定が可能です。 DBとJSONLでタスク管理 DBファイルとjsonlファイルの2つを用いてタスクを管理します。 DBファイル上でタスクのステータス、優先度、説明などが記録されています。 軽量な内部DBにクエリを実行することで、エージェントは必要な情報のみを参照でき、コンテキストの肥大化を防げます。 DBへの変更はjsonlファイルにも同期され、人間にも読みやすい形式で表示されるため、Gitなどのバージョン管理ソフトで差分を確認できます。 ローカルのDBファイルを用いるので、クラウドを使わずオフラインでも動作します。 コマンドラインから操作できるので、AIエージェントからも操作が可能です。 エージェントにセッションをまたいだ情報を記憶させるrememberコマンドなど、エージェント向けの機能があります。 初回セットアップ # Windowsにbeadsをインストール irm https://raw.githubusercontent.com/gastownhall/beads/main/install.ps1 | iex ## 環境変数 Pathに以下のPathを設定 >> ==> bd installed to C:\Users\pocke\AppData\Local\Programs\bd\bd.

はじめに 会社員からフリーランスエンジニアとして独立すると、多くの方が驚くのが健康保険料の負担です。 会社員時代は給与から天引きされ、金額をあまり意識していなかった方でも、独立後に自分で保険料を計算・納付する立場になると、想像以上の金額に驚くケースが少なくありません。 特にフリーランスエンジニアは、案件の単価が比較的高く、所得が上がりやすい職種のため、国民健康保険料も高額になりがちです。 この記事では、フリーランスエンジニアが検討すべき健康保険の主な選択肢を整理し、それぞれのメリット・デメリット、保険料の考え方について解説します。 最終的な選択や保険料の具体的な試算については、お住まいの自治体窓口や社会保険労務士、税理士に確認することをおすすめします。 フリーランスエンジニアが健康保険で直面する課題 国民健康保険料が高くなる理由 会社員が加入する協会けんぽ等の健康保険は、保険料を会社と折半するため、個人の負担は所得の一定割合に抑えられています。 一方、独立後に多くの方が加入する**国民健康保険（国保）**は、原則として以下の要素で保険料が計算されます。 所得割: 前年の所得に応じて金額が上がる部分 均等割: 世帯の加入者数に応じてかかる定額部分 平等割: 世帯ごとにかかる定額部分（自治体によって有無が異なる） このうち所得割は、所得が増えるほど比例して保険料が上がっていく仕組みのため、独立して所得が伸びたフリーランスエンジニアほど、国保料の負担も重くなりやすいという特徴があります。 なお、国民健康保険には保険料の**上限額（賦課限度額）**が設定されており、青天井に上がり続けるわけではありません。ただし、上限額自体も年々見直されており、高所得層にとっては依然として大きな負担になりやすい制度です。 会社員時代との違い 会社員の健康保険と異なり、国民健康保険には以下のような特徴もあります。 保険料の労使折半がなく、全額自己負担 傷病手当金・出産手当金が原則として支給されない（自治体や制度改正状況によって例外あり） 前年所得をもとに保険料が決まるため、独立初年度は前職の給与所得がベースになることがある こうした違いを理解した上で、自分に合った健康保険の選択肢を検討することが重要です。 主な選択肢の比較 フリーランスエンジニアが検討できる健康保険の選択肢は、大きく**国民健康保険（国保）と社会保険（社保）**の2系統に分かれます。 さらに国保は「市区町村国保」と「国民健康保険組合」の2種類、社会保険は法人の役員・従業員になることで加入するため、フリーランスが社会保険につながるルートとして「任意継続」「マイクロ法人」「社保加入代行」の3通りがあります。 健康保険は大きく以下のように分類されます。 国民健康保険団体（国保） 市区町村国保 国民健康保険組合（同業者組合） 社会保険団体 (社保) 全国健康保険協会（協会けんぽ） 健康保険組合 (組合健保) 共済組合 社会保険加入方法 任意継続被保険者制度 マイクロ法人スキーム 社保加入代行・一般社団法人加入 国民健康保険（国保） 市区町村国保 最も一般的な選択肢で、独立後に手続きをしなければ自動的にこの制度の対象になります。 市町村ごと微妙に保険料が異なるため、保険料が安い市町村で開業することで微小ですが保険料を抑えることができます。 メリット 手続きが比較的シンプルで、市区町村の窓口で完結する デメリット

はじめに Azure SRE Agent では、ユーザーが特定のタスクを実行するための特化したエージェントを、カスタムエージェントとして定義・作成することができます。 本記事では、カスタムエージェントの定義方法から実際の活用方法まで、詳しく解説します。 カスタムエージェントとは カスタムエージェントは、ユーザーが入力した特定のタスクを実行するために特化したエージェントです。 標準的なSREエージェントではカバーしきれない、特殊な役割や機能を必要とする場合に活用します。 カスタムエージェントの定義方法 カスタムエージェントは以下のようにYAML形式で定義できます。 name: database_expert system_prompt: |You are a database specialist. Analyze query performance, diagnose connection issues, and recommend optimizations. handoff_description: Handles SQL and database troubleshooting tools: - execute_kusto_query - azure_cli connectors: - azure_sql enable_skills: true # Can use skills for additional expertise 定義要素の説明 要素 説明 name カスタムエージェントの識別子 system_prompt カスタムエージェントの役割や動作を定義するプロンプト handoff_description オーケストレーターがこのカスタムエージェントにタスクを委任する判断基準となる説明文 tools カスタムエージェントが使用できるツール（azコマンド、外部APIなど） connectors 接続するAzure リソースやサービス enable_skills 有効にするとカスタムエージェントがスキルに動的にアクセス可能 重要な注意点 SRE エージェントのカスタムエージェントは、Claude Code のサブエージェントとは異なり、使用するモデルを指定することができません。

はじめに Azure SRE Agentは、Azure Monitorやログなどの監視データを活用してインシデント対応を支援するAIエージェントです。 その能力を最大限に引き出す鍵となるのが「コネクタ」機能です。 コネクタを設定することで、SREエージェントはAzure Monitor、Application Insights、Log Analyticsといった監視サービスや、GitHubリポジトリ、Teamsなどの外部サービスとシームレスに連携できるようになります。 本記事では、Azure SRE Agentのコネクタの概要、サポートされているサービス、導入するメリット、そしてApplication InsightsとLog Analyticsの違いについて解説します。 Azure SRE エージェントのコネクタ エージェントには、Azureサービスへの組み込みアクセスが用意されています。 コネクタは、外部サービスとSREエージェントを接続し、SREエージェントから外部サービスへのクエリの実行や、コードの読み取り、通知の送信を可能にします。 Azure公式ドキュメント: SREエージェントのコネクター サポートされているコネクタ Azure Monitor Application Insights Log Analytics Azure Resource Graph GitHubリポジトリ Teams カスタムAPI コネクタのメリット コネクタが設定されていない場合でも、SREエージェントは az コマンドが組み込まれているので、azコマンドを使ってApplication Insights、Log Analyticsなどへのクエリの検索は可能です。 敢えてコネクタを設定するメリットとしては、以下の点があります。 コネクタを使用するメリット： 毎回対象を指定しなくてもよい - 特定のLog AnalyticsワークスペースやApplication Insightsリソースをエージェントが継続的に認識 接続先のデータがコンテキストに入る - 接続先の監視データが前提知識として扱われやすくなり、調査時の文脈理解が速くなる 高度な診断がしやすくなる - 接続されたリソース全体をまたいだMCPベースの診断に使え、組み込みで提供されたToolsが使える コネクタは「単にクエリできるようにする」ためだけでなく、「どの監視データを常に見てよいかをエージェントに覚えさせ、継続的な診断能力を上げる」させることができます。 Application InsightsとLog Analyticsの違い Application Insightsで表示できるメトリクスはLog Analytics Workspacesに保存されます。 Log Analyticsだけでなく、Application Insightsを使うメリットとしてはLAWの情報を抽象化（アプリケーションマップなど機能）が使えるようになることです。