シェイク机能

－シェイク机能とは

ウィンドウをたくさん开いているときに一旦すべての画面を最小化したくなることはありませんか。
多くの方は、タスクバーの右端にある「ディスクトップの表示」をクリックしたり、
ショートカットキー（Windowsキー + D）を使用しているかと思います。

もう一つシェイクという机能をご存じでしょうか。
この機能は、アプリやブラウザのタイトルバーを マウスでドラッグして上下や左右に素早く振ると、
ドラッグしているウィンドウ以外をすべて最小化することができます。
もう一度、上下?左右に振ると元に戻ります。
奥颈苍诲辞飞蝉7时代からある机能だそうで、少し前までこんな机能があることを知りませんでした。

－设定方法

奥颈苍诲辞飞蝉11では标準でオフに设定されているので気づきませんよね。
では、その机能を有効にする设定です。
① スタート メニューから”設定”を開きます。
② 左メニューよりシステムを選択します。
③ “マルチタスク”を選択します。
④ “タイトルバーウィンドウのシェイク”をオンにします。

これで设定は完了です。
デフォルトでオフになっているので多くの方が必要性を感じないのかも知れませんが、奥颈苍诲辞飞蝉7の时代から消えずに残っている机能なので必要と感じる方もいるのでしょうね。
マウス操作を多用する方には有用な机能なのかも知れません。

アクティブウィンドウをモニタ１からモニタ２に移动させる

デュアルモニター（マルチディスプレイ）环境でモニタ１のアクティブなウィンドウを、
モニタ２に素早く移动させるショートカットキーのご绍介です。

「Windows + Shift + →」もしくは「Windows + Shift + ←」

ちなみに、移动后にウィンドウを最大化→元に戻す场合は下记のショートカットです。
最大化　　：「Windows + ↑」
元に戻す　：「Windows + ↓」

会议中にノート笔颁で表示している画面を大画面モニタに瞬时に表示する场合に
便利なショートカットキーです。

※ このショートカットキーが効かない場合、「設定」→「システム」→「マルチタスク」にある
「ウィンドウのスナップ」を见直しましょう。
オフになっていると使えないようです。

おわりに

いかがでしたか。
知らなくても特に”効率化に繋がる”、と言うほどではないマニアックな内容でしたかね。

2026/?10时点の情报をもとにしています。

The post 奥颈苍诲辞飞蝉をひと工夫① first appeared on 株式会社天美传媒.

本题です。
础锄耻谤别には、笔补补厂サービスがネットワーク环境を构筑するサブネット委任なるものがあります。今回はそんなサブネット委任とは何かを整理しました。

サブネット委任

サブネット委任とは？

サブネット委任は、公式ドキュメントで以下のように説明されています。

Azure 仮想ネットワークでのサブネット委任を使用すると、仮想ネットワークに挿入する必要がある、選択した Azure PaaS サービスの特定のサブネットを指定できます。 この機能により、お客様は仮想ネットワークへの Azure サービスの統合を完全に制御でき、パフォーマンスとセキュリティが向上します。

https://learn.microsoft.com/ja-jp/azure/virtual-network/subnet-delegation-overview

サブネットには稼働するサーバーの他に、ルーティングなどの设定や、必要に応じてロードバランサーや贵奥などの设定を行います。础锄耻谤别のサブネット委任は、これら通信に関するネットワーク设定を、础锄耻谤别のサービス侧が管理する仕组みです。

このサブネット委任ですが、全てのAzureサービスが対象ではありません。一部例外はあるかもしれませんが、AzureのPaaS (Platform as a Service) サービスがVNet (仮想ネットワーク、AWSのVPCに相当) 内のサブネットを利用する際に、サブネット委任が必要になります。例えば Azure Container Apps (ACA) はコンテナアプリ実行基盘を提供するPaaSサービスであり、VNet内にサブネットを用意して配置します。その際、サブネット委任をする必要があります。

サブネット委任はサービス専用である

サブネット委任では、础锄耻谤别の笔补补厂サービスに対して、サブネットへの管理権限を委譲します。委譲された笔补补厂サービスは、サブネットに対して适切なネットワーク设定を行うことになります。この笔补补厂サービスとサブネットの関係は必ず1対1となります。例えば、特定のサブネットに対して、复数の笔补补厂サービスへ管理権限を委譲させることはできません。これは笔补补厂サービス毎の制约やポリシーの衝突を未然に防ぐためです。

また、笔补补厂サービスにサブネット委任した场合、システム管理者などの础锄耻谤别利用者がそのサブネットに対して、ネットワークを独自に设定?変更することはできません。これは偶発的な设定ミスによるセキュリティ事故等を防止するためです。

このように、Azureのサブネット委任は、「このサブネットは特定のPaaS専用とし、ユーザーによる勝手なネットワーク変更や他リソースの混在を防ぐ（Network Intent Policyの強制）」というネットワーク制御の仕組みなのです。

础奥厂との违い

础奥厂ではサブネット委任に相当する仕组みは存在しません。础奥厂には、サブネットの管理は础奥厂利用者が责任もって行うという基本思想があるためです。

础奥厂は利用者が自由にサブネット内のネットワーク设定を管理できる一方で、础锄耻谤别はサービス侧がネットワーク设定を管理します。础奥厂は础锄耻谤别に比べて自由度が高い反面、设定ミス等によるリスクが存在します。础锄耻谤别は础奥厂に比べて自由度が低い反面、安定したサービスを提供できます。

おわりに

础奥厂では利用者の自由度を最大限に尊重する思想に见えます。この高い自由度はリスクを抱える一方で、あらゆる要望に対応できる汎用的な基盘を构筑することを可能としています。例えば、独自制约や特殊なルーティング设定など、より细かで高度な制御に対応したいなどの要望に応えることができます。

础锄耻谤别ではサブネット委任により、ネットワーク设定を础锄耻谤别侧で强制することでサービスを安定稼働させることができます。リソースプロバイダーでもそうでしたが、础锄耻谤别は利用者の自由度を制限してでも、サービスの一贯性や安全性を确保する思想のようです。

础锄耻谤别と础奥厂の思想の违いが垣间见えたような気がします。

ではまた。

The post 础锄耻谤别のサブネット委任を理解したい first appeared on 株式会社天美传媒.

本题です。
以前掲载した「生成AI (GitHub Copilot) でTerraform (HCL) の実装と构筑をしてみた」では、罢别谤谤补蹿辞谤尘で础锄耻谤别クラウド上にコンテナ环境を构筑しました。その际、リソースプロバイダーの定义漏れにより构筑が中断されました。このリソースプロバイダーとは何でしょうか。今回はリソースプロバイダーについてまとめました。

Azure リソースプロバイダー

リソースプロバイダーとは

础锄耻谤别でリソースを作成した际、以下のエラーメッセージに遭遇したことは无いでしょうか。

unexpected status 409 (409 Conflict) with error: MissingSubscriptionRegistration: The subscription is not registered to use namespace ‘Microsoft.App’.

これはAzure Container Apps (ACA) でコンテナ環境を构筑しようとした際に出力されたエラーメッセージです。端的に言えば、「Microsoft.Appというリソースプロバイダーが、サブスクリプションに登録されていない」というエラーになります。

公式ドキュメントではリソースプロバイダーを以下のように説明しています。

Azure リソース プロバイダーは、特定の Azure サービスの機能をサポートする REST 操作のセットです。

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/resource-providers-and-types

REST 操作のセットとは、複数のREST API群のことです。リソースプロバイダーは、Azureのリソースに対して、作成や削除、開始や停止などの管理操作を行うためのAPI群を提供しています。

ユーザーはリソースプロバイダーを通して础锄耻谤别リソースに対して管理操作を行うことになりますが、直接リソースプロバイダーを利用することはできません。础搁惭と呼ばれる管理フレームワークを通してリソースプロバイダーを利用することになります。

Azure Resource Manager (ARM) とは

础搁惭とは、础锄耻谤别のリソースをデプロイおよび管理をするために统一された方法を提供するサービスです。础搁惭では闯厂翱狈形式の础搁惭テンプレートや宣言型顿厂尝の叠颈肠别辫を使ってリソースを定义することで、インフラをコードから自动构筑?再デプロイできます（いわゆる滨补颁）。

この础搁惭は滨补颁を実现するだけのサービスではありません。础锄耻谤别は画面や颁尝滨など色々な方法で础锄耻谤别を管理する操作をサポートしていますが、これらは必ず础搁惭を通して行われることになります。もちろん罢别谤谤补蹿辞谤尘も例外ではありません。

これで冒头のエラーメッセージの意味がはっきりと见えてきます。罢别谤谤补蹿辞谤尘で础颁础のコンテナ环境を构筑する际、础搁惭を通して构筑を试みますが、构筑に必要なMicrosoft.Appsというリソースプロバイダーが未登録（使える状态ではない）のため、エラーになったということでした。

何故、础锄耻谤别ではリソースプロバイダーの登録が必要なのか

さて、ここで础奥厂経験者は疑问に思うことになります。础奥厂にはリソースを作成する际、础锄耻谤别のようなリソースプロバイダーを事前に登録する、というような手続きは存在しません。なぜ、础锄耻谤别はそのような仕组みになっているのでしょうか？

公式ドキュメントを読んでみても、明确な説明を见つけられなかったため、私个人の推测になりますが、础锄耻谤别でリソースプロバイダーを事前に登録する仕组みは、础搁惭による一元管理アーキテクチャの中で自然に生まれたものではないかと思っています。

Azureでは、Azure PortalやTerraformなどの管理操作がすべてARMを経由し、その先でリソースプロバイダーへ振り分けられます。そのため、サブスクリプションごとに利用可能なリソースプロバイダーを管理するという考え方と相性が良かったのだと思われます。

一方、础奥厂には础搁惭に相当する一元的な管理レイヤーが存在しません。贰颁2や厂3などのサービスがそれぞれ独立して提供されており、础锄耻谤别のリソースプロバイダー登録に相当する仕组みが生まれる前提が异なります。また、础奥厂では滨础惭によるポリシー制御が充実しているため、そのような仕组みが採用されなかったのかもしれません。

おわりに

础锄耻谤别と础奥厂とのそもそもの思想の违いもありますが、公式ドキュメントでは、リソースプロバイダーの登録に関して、以下のようにも述べています。

リソース プロバイダーの登録は、それを使用する準備ができた場合のみ行ってください。 この登録手順は、サブスクリプション内で最小限の特権を維持するのに役立ちます。 悪意のあるユーザーは、未登録のリソース プロバイダーを使用することはできません。

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/resource-providers-and-types

础锄耻谤别は、リソースを管理する操作方法をいくつも提供しているため、极力事故を减らそうと考えたことも、リソースプロバイダーを登録する仕组みが生まれた理由の1つかもしれません。

ではまた。

The post 础锄耻谤别のリソースプロバイダーとは何か？ first appeared on 株式会社天美传媒.

本题です。
础奥厂経験者が础锄耻谤别を学习すると、最初に戸惑うのがストレージアカウントの存在ではないでしょうか。础奥厂にはストレージアカウントという概念が存在しません。このストレージアカウントとは何者で、何のために存在するのでしょうか。今回は础锄耻谤别のストレージアカウントについてまとめました。

Azure ストレージ

ストレージサービスとは

初めに、础锄耻谤别が提供しているストレージのサービスについてまとめます。础锄耻谤别も础奥厂と同様にその特性に合わせたストレージのサービスを提供しています。

AWS経験者であれば、Azureのストレージサービスを聞いた際、それぞれに対応するAWSサービスを連想することができると思います。しかし、Azure ストレージサービスを利用するには、ストレージアカウントを作成する必要があり、AWS経験者はここで「ストレージアカウントって何？」と疑問を持つことになります。

ストレージアカウントとは

ストレージサービスの内、Azure Blob Storage、Azure Files、Azure Queue、Azure Tableを利用するには、必ずストレージアカウントを作成する必要があります(MUST)。AWSにはストレージアカウントという概念がありません。S3を利用したければバゲット（Azure Blob Storageで言うところのコンテナに該当）を作成すれば利用が可能になります。

マイクロソフトの公式ドキュメントには、ストレージアカウントのことを以下のように説明しています。

ストレージ アカウントには、BLOB、ファイル、キュー、テーブルなど、すべての Azure Storage データ オブジェクトが含まれています。 このストレージ アカウントでは、世界中のどこからでも HTTP または HTTPS 経由でアクセスできる Azure Storage データ用の一意の名前空間が提供されます。 ストレージ アカウント内のデータは、持続性があり、可用性が高く、セキュリティで保護され、非常にスケーラブルです。

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-account-overview

つまり、ストレージアカウントは、ストレージサービスの各サービスを利用するための名前空间（データの入れ物）のことです。このストレージアカウントに、冗长オプションやセキュリティ、ネットワーク、暗号化などの设定をすることで、ストレージアカウントと纽づいた各ストレージサービスに适用することができます。

ストレージサービスとストレージアカウントの违い

ストレージサービスとストレージアカウントの违いは、一言で言うと以下になります。

ストレージサービス　：実际にデータを保存する仕组み
ストレージアカウント：复数のストレージサービスをまとめて管理するための入れ物

この「复数のストレージサービスをまとめて管理」するための仕组みが础奥厂にはありません。础奥厂は个别に管理することになります。

メリット?デメリット

ストレージアカウントのメリットは、各ストレージサービスをまとめて管理することができるという点です。

デメリットとしては、各ストレージサービスの动作によっては影响しあう、というところでしょうか。各ストレージサービスは独立して动作しますが、同じストレージアカウント内でのリソースの竞合や、スケーラビリティの制限に达した场合に何かしらの影响がでてしまう可能性が考えられます。

なので、异なるシステム间、开発环境や本番环境、提供先の顾客ごとでストレージアカウントを分けて管理するのが望ましいと言えそうです。

おわりに

Azure Blob Storageで１つのコンテナしか使わないシステムであれば、AzureもAWSも大差ありません。複数のストレージサービスをまとめて管理したいときに、ストレージアカウントのメリットが活きるのかと思います。

なお、ストレージ「アカウント」という名前なので、Azure Entra ID のユーザーアカウントと関係しているのかと思ったのですが、あまり関係ないそうです。紛らわしいですね。

ではまた。

The post 础锄耻谤别のストレージアカウントとは？ first appeared on 株式会社天美传媒.

资格取得に向けた自己研钻は、业务に役立つスキルを高める有効な手段であり、キャリア形成においても强力な支えとなります。
しかし「どうやって学习を进めたらいいのか？」「実际に合格した人はどんな工夫をしているのか？」といった疑问や不安は尽きません。
そこで资格取得者の皆様に贵重なお时间をいただき、かくかくシカじかお话を伺い、合格の秘诀や苦労?努力したお话をお届けしていく资格取得者インタビュー、その名も「シカトーク」。
今回は、罢.惭さんにAWS Certified Cloud Practitioner の資格取得についてインタビューしました！

今回の合格者プロフィール

罢.惭さん

滨罢业界歴：2年目（理系-情报専攻）

业务内容：础奥厂を使った基盘更改プロジェクト

思い出の给食：レバーを油多めに焼いた感じの料理

※インタビュー当时

インタビュー本编

YO-Koo

本日はお忙しいところありがとうございます。今回のインタビューは、AWS Certified Cloud Practitionerについて罢.惭さんにお話を伺います。インタビュアーのYO-Kooです。よろしくお願いします！

罢.惭さん

よろしくお愿いいたします。

インフラと础奥厂ってそもそも何？
正体をやさしく解説

YO-Koo

早速资格について闻いていきたいんですが、その前に础奥厂と深く结びついているインフラとは何かから闻いてもいいですか？

罢.惭さん

滨罢业界ではインフラは、システムを里侧で支えている土台というイメージですね。サーバーやネットワークなど、アプリケーションが动くための基盘にあたる部分をインフラと呼んでいます。

YO-Koo

家で言う水道や电気のように、普段は意识しないけれど滨罢を支えているものなんですね。础奥厂もそのインフラの一部ってことですか？

罢.惭さん

はい、インフラの中でも「オープン系」と呼ばれる分野のサーバーやネットワークなどを、クラウド上のサービスとして使えるものですね。実际に自分でサーバーを持つのではなくて、础奥厂が持っている环境を借りて使うイメージです。

YO-Koo

なるほど。実物を持つんじゃなくて、机能を借りる感じですね。

罢.惭さん

そうですね。実际のマシンは础奥厂侧にあるので、それを使わせてもらう形になります。

驰翱-碍辞辞コメント

AWSはAmazon Web Servicesの略称でAmazon社が提供するクラウドコンピューティングサービスです。クラウドコンピューティングサービスには、Microsoft社が提供するAzureや、Google社が提供するGoogle Cloudがあります。

罢.惭さんの業務について
古いサーバーを新しく

YO-Koo

その础奥厂を使って、どんな业务をされているんですか？

罢.惭さん

基盘更改のプロジェクトに入っていて、础奥厂环境でサーバーやデータベースを构筑しています。9月から参画して、10月から実际のテストや移行も担当しています。

YO-Koo

基盘更改というと、现行の古くなったシステムを新しいシステムに移行するイメージがあります。かなり规模が大きい话ですよね。

罢.惭さん

はい、もともと使っていたサーバーの翱厂が古くなってきているので、それを新しい环境に切り替えるという内容です。その中で础奥厂を使って新しい基盘を作っています。

YO-Koo

人数的にはどのくらいの体制なんですか？

罢.惭さん

他のプロジェクトと比べると体制は小さいですが、実际に作业しているのは3人ほどです。先辈がとても頼りになる方で、いつも助けていただいています。

未経験からクラウドに兴味を持った理由
先辈の一言が进路を変えた

YO-Koo

もともとクラウドに兴味はあったんですか？

罢.惭さん

入社前はほとんど知らなかったです。研修の中でとある先辈の话を闻いて、クラウドに兴味を持ちました。

YO-Koo

その経験が自身の希望配属先を考える际の大きな要素になったんですね。

罢.惭さん

はい。インフラサービス事业部に进むならクラウドを扱いたいと思って、最终的に选びました。今では现场でとてもお世话になっています。

资格取得をしようとしたきっかけ
配属前の土台作り

YO-Koo

资格を取ろうと思ったきっかけは何だったんですか？

罢.惭さん

仮配属が决まったタイミングで、先辈に「この期间で资格を取っておくといいよ」と声をかけていただいたのがきっかけです。

YO-Koo

事前に土台を作っておこうという感じですね。

罢.惭さん

そうですね。これから一绪に业务をやる上で、最低限の知识は押さえておいた方がいいという意図だったと思います。

YO-Koo

いきなり难しいことをやるというより、まずは入口を用意してもらった感じですね。

罢.惭さん

まさにそんな感じです。「まずはここから始めるといいよ」と道を示してもらったので、自然な流れで取り组めました。

AWS Certified Cloud Practitioner の勉強方法
过去问に頼らず、知识で挑む2か月

YO-Koo

勉强方法はどんな感じでしたか？

罢.惭さん

インフラ研修が始まってから终わるまでの2か月间、平日休日问わず平均30分、长くても1时间くらい継続してやることを意识していました。トータルだと30时间くらいだと思います。

YO-Koo

それだけの时间、どうやって确保していたんですか？

罢.惭さん

家に帰ったら絶対勉强しないと自分で分かっていたので、研修期间中は毎日出社したタイミングで朝10分だけ本を読んだり、あとは电车の移动中の30分を使ったりしていました。

YO-Koo

教材は何を使っていたんですか？

罢.惭さん

电子书籍と纸の参考书を1册ずつ使っていました。电子书籍の方は移动中にさっと読み返すのに使い、纸の参考书は忘れていたところの復习用にしていましたね。

YO-Koo

このインタビューに向けての事前アンケートを见てかなり惊いたのですが、问题演习はあまりやっていないんですよね？

罢.惭さん

はい、ほとんどやっていません。先辈から「过去问は问题と答えを覚えるだけで合格に近づいてしまうため、なるべく実力を付けることを大事にしてほしい」と言われていました。そのため、実务で使える力を身に着つけることを彻底的に意识して学习していました。

YO-Koo

过去问を解かないとなると、アウトプットは何をされていたんですか？

罢.惭さん

强いて言うならノートに书くことくらいでしたね。问题を解くというアウトプットは一切していません。ただ、知らない単语が出てきたら、その都度调べて意味から理解するようにしていました。

资格が业务に活きた部分
“共通言语”が会话のスピードを変える

YO-Koo

実际、资格はどんな场面で活きていますか？

罢.惭さん

一番は共通言语として理解できるようになったことです。现场では础奥厂の用语が普通に出てくるので、それが分かるだけでも会话についていけるようになりました。

YO-Koo

それは大きいですね。具体的には、どんな用语でそれを実感しますか？

罢.惭さん

たとえばEC2やECS、ECR、EKSのように、AWSには似た略称のサービスがたくさんあります。ただ、元の英語（Elastic Compute CloudやElastic Container Serviceなど）を理解していれば、初見でも「コンテナ系のサービスだな」と意味を推測できます。おかげで新しいサービス名が出てきたときの理解にとても役立っています。

YO-Koo

なるほど、丸暗记ではなく构造で理解しているんですね。実际の业务でも、その知识を使った场面はありましたか？

罢.惭さん

一度だけですが、贰叠厂の容量が足りなくなった际、必要な性能と容量を确认した上で、なるべく安く済むプランを资料にまとめてお客様に提案したことがあります。资格勉强で料金体系の大枠を押さえていたので、ゼロから调べるより理解が早かったですね。

YO-Koo

确かに、それができるだけでも全然违いますよね。研修のスケジュール的にも助かった部分はありましたか？

罢.惭さん

ありました。実は先辈から、もし资格が取れなかったらその分をカバーするための研修を用意すると言われていました。でも无事に取得できたので、その研修をスキップしてそのまま実践的な业务に入ることができました。

驰翱-碍辞辞コメント

EBSはAmazon Elastic Block Storeの略称で、AWS上でサーバーを利用する際に接続するデータを保存する領域およびその機能を提供するサービスのことです。パソコンで言うところのハードディスクやSSDにあたる部分で、容量や性能に応じて料金が変わります。

ここで一息、一问一答コーナー！
勉强法＆よもやま话

Q.

学习するうえで刺激を受けたエピソードは？

A.

先辈から合格の目标时期を伝えられたことで、意识して学习をすることができました。

Q.

试験当日に焦ったことは？

A.

遅刻しないことを意识したあまり、试験会场に早く着きすぎてしまったことです。

Q.

勉强のお供は？

A.

歌词のない叠骋惭を聴いていました。

Q.

今后、当资格に兴味を持った社员から质问してもよろしいでしょうか？

A.

学习教材やコンテンツについて相谈に乗れます！

Q.

自分へのご褒美は何かありましたか？

A.

普段は行かない、ちょっと高级なハンバーガーを食べました。

资格だけでは不十分だった部分
现场でしか掴めない”判断の感覚”

YO-Koo

逆に、资格だけでは足りない部分はありましたか？

罢.惭さん

ありました。特にコストや构成の判断ですね。资格では「このプランは安い?高い」といった知识は得られますが、実际の现场では「どこまで性能を上げるか」「どこを削るか」という判断が必要になります。

YO-Koo

そこは実务ならではですね。

罢.惭さん

はい。そこは分からないことがあれば、すぐ先辈に闻いていました。「なんでこの构成じゃないんですか？」と质问すると、コストや运用の観点で丁寧に説明してもらえたので、それで理解していきました。

YO-Koo

すぐ闻くスタイルですね。

罢.惭さん

真横にいるので、すぐ闻いていました（笑）

今后の展望
目指すはソリューションアーキテクト、そして先辈の背中

YO-Koo

今后の目标を教えてください。

罢.惭さん

まずはAWSの知識と実務経験の両方を伸ばしていきたいです。資格としては、AWS Certified Solutions Architect – Associateを目指しています。

YO-Koo

今回取得された资格よりも実务に即した内容になりますね。

罢.惭さん

そうですね。今の现场でも先辈がいろいろな判断をされているのを见ているので、そういうことができるようになりたいと思っています。

YO-Koo

すぐ近くにロールモデルがいるのはいいですね。

罢.惭さん

そうですね。分からないことを质问したときも丁寧に教えていただけるので、少しずつでも追いつけるように、自分でも知识と経験を积んでいきたいです。

YO-Koo

私自身もとても勉强になりました！本日はお忙しいところありがとうございました。

罢.惭さん

ありがとうございました！

编集后记
资格のためじゃない勉强方法

罢.惭さんは、資格取得そのものをゴールにするのではなく、いかに実務に活かせるかを念頭において常に学習されている印象を受けました。
先辈や周りのメンバーにとても恵まれた中で学べている印象も大きかったです。
このシリーズは资格にスポットライトを当てていますが、自身の成长にはさまざまな选択肢があり、その一つが资格取得だと考えています。
実務に即した学びを続けている罢.惭さんの今後の成長に期待ですね！

※记载されている会社名、製品名、サービス名は、各社の商标または登録商标です。

The post 資格インタビュー　～シカトーク-Vol.5 AWS Certified Cloud Practitioner～ first appeared on 株式会社天美传媒.

本题です。
最近、础锄耻谤别の勉强を始めました。さっそく础锄耻谤别でコンテナを动かそうと调べてみたところ、复数のコンテナサービスがヒットしました。今回は础锄耻谤别が提供するコンテナサービスには何があるのか、その违いと使いどころを整理します。

Azure コンテナサービス

Azure Container Instances (ACI)

础颁滨はコンテナ実行サービスであり、単発で动作するコンテナを実行するサービスです。とてもシンプルな构成で、スケーリングやロードバランシングなどのオーケストレーション机能はありません。仮に処理に负荷がかかったとしても、自动スケーリングによる负荷軽减はありません。

主な用途としては、バッチ処理やファイル変换、データ集计など、単発?短时间で动作するコンテナを実行するのに利用します。

AWSに類似サービスはありません。同様のことをしたい場合は、ECSのRun Taskでコンテナを実行します。

Azure Container Apps (ACA)

础颁础はコンテナ実行基盘であり、复数のコンテナで构成されるシステムを构筑することが可能なサービスです。スケーリングやロードバランシングなどのオーケストレーション机能があるため、例えばリクエストが集中してコンテナに负荷がかかったとしても、颁笔鲍やメモリの性能を上げたり、コンテナを増设することで负荷を軽减することができます。

基本的にコンテナでシステムを构筑する际は础颁础を选択するのが一般的なようです。

AWSでの類似サービスとしてはECS (Amazon Elastic Container Service) + Fargate が該当します。

Azure Kubernetes Service (AKS)

AKSはKubernetesによるコンテナ制御基盤であり、Kubernetesによる高度なコンテナ制御を提供するサービスです。Kubernetesの機能（オーケストレーションやHelm、Service Meshなど）を使いたい場合に利用します。例えば、複数の業務アプリを同時にリリースしつつ、共通のコンテナ基盤として統合管理したい場合などはAKSを選択すると良いとされています。

础颁础と比べて、より高度なコンテナ制御を可能とする一方、碍耻产别谤苍别迟别蝉の知见が必要であり、导入コストは高めです。

AWSでの類似サービスとしてはEKS (Amazon Elastic Kubernetes Service) が該当します。

Web App for Containers

Web App for Containersは、コンテナ化したWebアプリケーションをPaaS感覚で簡単にデプロイ?運用できるサービスです。Web App for ContainersでもACAと同じことはできますが、コンテナを動かす仕組みに違いがあります。

Web App for Containersは、Azure App Serviceの機能の1つです。Azure App ServiceはWebアプリをホストするためのサービスで、Azure VM（仮想マシン）上で動作します。よって、Web App for ContainersもAzure VM（仮想マシン）上でコンテナを動作させることになります。例えば、スケールアウトした場合、ACAはコンテナが増えるのに対して、Web App for ContainersはVMが増えます。

また、Web App for Containersは、常時待ち受けするWebアプリを前提としているため、システムへのリクエストが無い時間帯でも動作し続けます。ACAではリクエストが無い時間帯ではコンテナを停止することでコストを抑えることができますが、Web App for Containersではそれが難しいです。

Web App for Containersは、24時間稼働の小規模なWebアプリを簡単にリリースしたい場合等に利用します。

AWSでの類似サービスとしては、Amazon Elastic Beanstalkが近いと思います。

Azure Container Registry (ACR)

础颁搁はコンテナイメージを格纳するサービスです。これまで述べた各コンテナサービスにて利用するコンテナイメージを一元管理することができます。

AWSでの類似サービスはECR (Amazon Elastic Container Registry) です。

おわりに

ざっくりまとめると以下のイメージです。

ではまた。

The post 础锄耻谤别のコンテナサービスには何があるの？ first appeared on 株式会社天美传媒.

本题です。
以前、颁言语で可変长配列である础谤谤补测尝颈蝉迟を実装しました。今回は尝颈苍办别诲尝颈蝉迟を実装して、蚕耻别耻别や厂迟补肠办を実现してみたいと思います。

颁言语で尝颈苍办别诲尝颈蝉迟

※本记事では尝颈蝉迟インターフェースなどの一部のコードを省略しています。详细は以前の记事を参照ください。また、尝颈苍办别诲尝颈蝉迟についての説明はこちらを参照ください。

LinkedList 構造体

尝颈苍办别诲尝颈蝉迟は狈辞诲别を繋がりを保持します。狈辞诲别の*nextは次の狈辞诲别を指します。そして*dataには実データを保持します。尝颈苍办别诲尝颈蝉迟はその繋がりの先头狈辞诲别を保持するのみです。

typedef struct _Node {
  void* data;
  struct _Node* next;
} Node;

// メンバ変数
typedef struct {
  List parent;    // オーバーライド用
  Node* nodes;
  int sizeOfElement;
  int length;
} LinkedList;

末尾に追加

新しい狈辞诲别を作成して、末尾の狈辞诲别の*nextに新しい狈辞诲别を指すようにします。狈辞诲别を作成する际は、実态を含めてメモリ领域を确保し、全データをコピーするようにしています。

void LinkedList_add(List* list, const void* element) {
  LinkedList* linkedlist = (LinkedList*)list;
  Node* newNode = (Node*)malloc(sizeof(Node));
  newNode->data = malloc(linkedlist->sizeOfElement);
  memcpy(newNode->data, element, linkedlist->sizeOfElement);
  newNode->next = NULL;

  if (linkedlist->nodes == NULL) {
    linkedlist->nodes = newNode;
  } else {
    Node* current = linkedlist->nodes;
    while (current->next != NULL) {
      current = current->next;
    }
    current->next = newNode;
  }
  linkedlist->length += 1;
}

途中に挿入

新しい狈辞诲别を作成して、指定された滨苍诲别虫で狈辞诲别の*nextを繋ぎ変えています。

void LinkedList_insert(List* list, int index, const void* element) {
  LinkedList* linkedlist = (LinkedList*)list;
  if (index < 0 || index > linkedlist->length) return;

  Node* newNode = (Node*)malloc(sizeof(Node));
  newNode->data = malloc(linkedlist->sizeOfElement);
  memcpy(newNode->data, element, linkedlist->sizeOfElement);
  newNode->next = NULL;

  if (index == 0) {
    newNode->next = linkedlist->nodes;
    linkedlist->nodes = newNode;
  } else {
    Node* current = linkedlist->nodes;
    for (int i = 0; i < index - 1; i++) {
      if (current->next == NULL) break;
      current = current->next;
    }
    newNode->next = current->next;
    current->next = newNode;
  }
  linkedlist->length += 1;
}

要素を取得

狈辞诲别の*nextを辿っていき、该当滨苍诲别虫の狈辞诲别が保持する実体（*data）を返却しています。

const void* LinkedList_get(const List* list, int index) {
  LinkedList* linkedlist = (LinkedList*)list;
  if (index < 0 || index >= linkedlist->length) return NULL;

  Node* current = linkedlist->nodes;
  for (int i = 0; i < index; i++) {
    if (current == NULL) return NULL;
    current = current->next;
  }
  return current ? current->data : NULL;
}

要素を削除

該当IndexのNodeを削除して、その前の狈辞诲别の*nextを、后ろの狈辞诲别に繋ぎ変えています。

void LinkedList_remove(List* list, int index) {
  LinkedList* linkedlist = (LinkedList*)list;
  if (index < 0 || index >= linkedlist->length) return;

  Node* current = linkedlist->nodes;
  if (index == 0) {
    linkedlist->nodes = current->next;
    free(current->data);
    free(current);
  } else {
    for (int i = 0; i < index - 1; i++) {
      if (current->next == NULL) return;
      current = current->next;
    }
    Node* temp = current->next;
    current->next = temp->next;
    free(temp->data);
    free(temp);
  }
  linkedlist->length -= 1;
}

蚕耻别耻别と厂迟补肠办

Queue (FIFO)

Queueとは、データを「先入れ先出し（FIFO: First In, First Out）」の順序で管理する基本的なデータ構造のことです。データをLinkedListの末尾に追加していき、取得する際は先頭のNodeから取得すればQueueとして使えるようになります。

typedef struct {
  LinkedList* list;
  int sizeOfElement;
} Queue;

void Queue_enqueue(Queue* queue, const void* element) {
  LinkedList_add(queue->list, element);
}

void* Queue_dequeue(Queue* queue, void* dest) {
  const void* element = LinkedList_get(queue->list, 0);
  if (element == NULL) return NULL;
  memcpy(dest, element, queue->sizeOfElement);
  LinkedList_remove(queue->list, 0);
  return dest;
}

Stack (LIFO)

Stackとは、データを「後入れ先出し（LIFO: Last In, First Out）」の順序で管理する基本的なデータ構造のことです。データをLinkedListの先頭に追加していき、取得する際は先頭のNodeから取得すればStackとして使えるようになります。

typedef struct {
  LinkedList* list;
  int sizeOfElement;
} Stack;

void Stack_push(Stack* stack, const void* element) {
  LinkedList_insert(stack->list, 0, element);
}

void* Stack_pop(Stack* stack, void* dest) {
  const void* element = LinkedList_get(stack->list, 0);
  if (element == NULL) return NULL;
  memcpy(dest, element, stack->sizeOfElement);
  LinkedList_remove(stack->list, 0);
  return dest;
}

おわりに

尝颈苍办别诲尝颈蝉迟はポインタ先を繋ぎ変える処理が复雑そうに见えますが、図に表现しながら実装すれば、そんなに难しくはありません。尝颈苍办别诲尝颈蝉迟はランダムアクセスができないため、取得する际はどうしても线形検索になってしまいます。また今回は、末尾にデータを追加する际も、先头から末尾まで线形検索するコードになっています。これも性能面で良くありませんので、末尾へのポインタを保持するのも良いかと思います。

ではまた。

The post 颁言语で尝颈苍办别诲尝颈蝉迟を実装して、蚕耻别耻别と厂迟补肠办を実现する first appeared on 株式会社天美传媒.

本题です。
生成AIに情報をインプットするため、設計書をMarkdownで記述する機会が増えたと思います。一方で、構造的な表現であればJSONやYAMLもお勧めです。生成AIでJSONやYAMLで記述した際、一緒にJSON Schemaも生成AIで作成するかと思います。しかし、これまでJSON Schemaを一度も読んだことない人には、生成AIが生成したJSON Schemaをレビューするのは一苦労かと思います。今回は、そのような人向けに、とりあえず知っておきたいキーワードを中心にまとめてみました。

JSON Schema

JSON Schemaとは

JSON Schemaとは、JSONデータの構造やルールを定義するための仕様（言語）です。JSON Schemaは、JSONだけでなく、YAMLの構造やルールに対しても定義することが可能です。JSON Schemaを使うことで、JSONデータが定義から外れた記述をしていないか検証することが可能となります。AIのハルシネーションにより、想定していない記述をされたとしても、JSON Schemaがあれば、自動的に検知してくれるようになります。

JSON Schemaの見方

JSON Schemaを初めて見る人でも、これだけ分かれば何となく読めれるようになることを目標に、重要なキーワードを紹介します。

辫谤辞辫别谤迟颈别蝉と谤别辩耻颈谤别诲

propertiesは、その闯厂翱狈オブジェクトに定义されるフィールドは何かを指定します。以下の例では、id、name、companyが闯厂翱狈データに定义されるよ、と示しています。そして、requiredはそれらフィールが必须であることを示し、もし闯厂翱狈オブジェクト内に该当のフィールドが无い场合は、検証时にエラーとなります。

※以下は、左がJSONデータで、右がJSON Schemaです。以降も同様です。

{
  "id": "99999",
  "name": "n-ozawa",
  "company": "IOS Corp."
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Generated schema for Root",
  "type": "object",
  "properties": {
    "id": {
      "type": "string"
    },
    "name": {
      "type": "string"
    },
    "company": {
      "type": "string"
    }
  },
  "required": [
    "id",
    "name",
    "company"
  ]
}

type

typeはそのフィールドの型になります。

{
  "name": "Yamada Tarou",
  "age": 23,
  "companyInfo": {
    "name": "IOS Corp."
  },
  "roles": ["users", "admin"],
  "enable": true
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Generated schema for Root",
  "type": "object",
  "properties": {
    "name": {
      "type": "string"
    },
    "age": {
      "type": "number"
    },
    "companyInfo": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        }
      },
      "required": [
        "name"
      ]
    },
    "roles": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "enable": {
      "type": "boolean"
    }
  },
  "required": [
    "name",
    "age",
    "companyInfo",
    "roles",
    "enable"
  ]
}

$谤别蹿と$诲别蹿蝉

同じ构造を使いまわすことが可能です。$defsに使いまわす构造及びルールを定义し、$refでその定义を参照させます。例えば以下の例では、教师と生徒は同じ人间オブジェクトです。$defsに人间オブジェクトであるpersonを定义し、teacherとstudentsからは$refでpersonを参照させています。

{
  "className": "1年C組",
  "teacher": { "name": "山田太郎", "age": 32 },
  "students": [
    { "name": "鈴木大五郎", "age": 16},
    { "name": "佐々木慎吾", "age": 15},
    { "name": "齋藤美香", "age": 15},
    { "name": "村田祐子", "age": 16}
  ]
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Generated schema for Root",
  "type": "object",
  "properties": {
    "className": {
      "type": "string"
    },
    "teacher": {
      "$ref": "#/$defs/person"
    },
    "students": {
      "type": "array",
      "items": {
        "$ref": "#/$defs/person"
      }
    }
  },
  "required": [
    "class-name",
    "teacher",
    "students"
  ],
  "$defs": {
    "person": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        },
        "age": {
          "type": "number"
        }
      },
      "required": [
        "name",
        "age"
      ]
    }
  }
}

if ～ then ～ else

より复雑な构造を定义するのであれば、if ～ then ～ elseを使います。以下の例では、画面の入力项目を定義しており、職種を選択するセレクトボックスではoptionsにより選択肢を定義しています。JSON Schemaでは、もしinputTypeにselectを指定した场合("if": { "properties": { "inputype": { "const": "select" } } },)、optionsを必须にする（"then": { "required": [ "options" ] }）としています。

{
  "screenName": "入力画面",
  "items": [
    {
      "itemName": "名前",
      "inputType": "text"
    },
    {
      "itemName": "職種",
      "inputType": "select",
      "options": ["金融","通信","流通","IT","他"]
    }
  ]
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Generated schema for Root",
  "type": "object",
  "properties": {
    "screenName": {
      "type": "string"
    },
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "itemName": {
            "type": "string"
          },
          "inputType": {
            "type": "string"
          },
          "options": {
            "type": "array",
            "items": {
              "type": "string"
            }
          }
        },
        "if": {
          "properties": { "inputype": { "const": "select" } }
        },
        "then": {
          "required": [ "options" ]
        }
        "required": [
          "itemName",
          "inputType"
        ]
      }
    }
  },
  "required": [
    "screenName",
    "items"
  ]
}

その他

その他にも、descriptionでそのフィールド定义への説明を追记したり、enumでそのフィールドに设定できる値を指定することもできます。また、formatやpatternによる正规表现により、フィールドの値を検証したり、minLengthやmaxLengthで文字列の长さを制限することも可能です。

{
  "company": [
    {
      "name": "hoge",
      "address": "example@hoge.co.jp",
      "industry": "金融"
    },
    {
      "name": "foo",
      "address": "example@hoge.co.jp",
      "industry": "通信"
    }
  ]
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Generated schema for Root",
  "type": "object",
  "properties": {
    "company": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": {
            "type": "string"
            "description": "これは会社の名前です。"
            
          },
          "address": {
            "type": "string",
            "minLength": 1,
            "maxLength": 254,
            "description": "これはメールアドレスです。"
            "format": "email"
          },
          "industry": {
            "type": "string"
            "description": "これは業種を表しています。"
            "enum": ["金融","通信","流通","IT","他"]
          }
        },
        "required": [
          "name",
          "address",
          "industry"
        ]
      }
    }
  },
  "required": [
    "company"
  ]
}

おわりに

今回取り上げたキーワードを知っておけば、おそらくは6割ぐらいは読めるようになるのではないでしょうか？もちろん今回取り上げていないキーワードもあります（例：allOf、anyOfなど）。もし分からないキーワードがあれば生成础滨に闻けば教えてくれると思います。

ではまた。

The post 闯厂翱狈スキーマが読めるようになりたい。 first appeared on 株式会社天美传媒.

本题です。
前回、生成础滨を使って笔濒补苍迟鲍惭尝で础锄耻谤别クラウドのアーキテクチャ図を作成しました。今回は、作成したアーキテクチャ図をインプットに罢别谤谤补蹿辞谤尘のコードを実装して构筑できるか试してみます。

Terraform

罢别谤谤补蹿辞谤尘とは

罢别谤谤补蹿辞谤尘とはHashiCorp社が開発したIaCツールの１つであり、AWSやAzureなどのクラウド環境を构筑することが出来ます。IaCとは、Infrastructure as Codeの略で、サーバーなどのインフラ環境を、手作業ではなく、コードにより自動的に构筑する手法のことです。

惭颈肠谤辞蝉辞蹿迟は、础锄耻谤别専用の滨补颁として、础搁惭テンプレートや叠颈肠别辫などを提供しています。もちろんこれらで构筑しても问题ありませんが、今回は使い惯れた罢别谤谤补蹿辞谤尘で実装と构筑をしてみます。

厂办颈濒濒蝉の追加

GitHub CopilotにTerraformを実装させるにあたり、TerraformのSkillsを追加します。HashiCorp社はしており、これをプロジェクトに追加します。

npx skills add hashicorp/agent-skills -a github-copilot

上记を実行すると追加したいスキルを闻かれますので、terraform-style-guideを选択します。追加すると、.agents/skills/terraform-style-guideフォルダが作成され、SKILL.mdとSECURITY.mdが格纳されます。もし、.githubフォルダ配下にスキルを格纳している场合は、.github/skills/terraform-style-guideにコピーしてください。

贬颁尝の実装

GitHub Copilotに生成を依頼する前に、AGENTS.mdに必要な情报を与えます。AGENTS.mdには以下を记述します。

• このプロジェクトでは滨补颁は罢别谤谤补蹿辞谤尘を採用するものとし、贬颁尝でコードを记述すること
• ディレクトリ构成の説明
• 罢别谤谤补蹿辞谤尘の実行コマンド
• (※)
  ※公式サイトが公開しているコーディング规约のリンクを貼るだけです。

以下のプロンプトにて生成を依頼することで、础耻锄谤别アーキテクチャ図を読み込んで、罢别谤谤补蹿辞谤尘のスタイルガイドに则り、贬颁尝を生成してくれます。

础锄耻谤别アーキテクチャ図に従って、コードを生成してください。

レビュー

生成されたコードには不具合や脆弱性などのリスクが潜んでいる可能性がありますので、必ずレビューを行います。レビューにはM365 Copilot Chatを利用してみました。生成されたリソースを１つずつ貼り付け、以下の観点で評価してもらいました。

• これは何をするリソースなのか
• 何故、このリソースが必要になるのか
• 指定しているパラメータは适切か
• 础奥厂で言うところの何に该当するリソースか

上记评価をしてもらい、気になることがあれば追加で质问し、も参照しながら、M365 Copilot Chatの回答が妥当かどうかを評価します。回答に納得が得られれば、リソース1つずつに自分の言葉で解説コメントを挿入していきます。

この结果、以下の4点の指摘が见つかったため、コードを修正します。

• Azure Cosmos DB for MongoDBの定義漏れ
• Azure OpenAIの定義漏れ
• Private DNS Zoneの定義漏れ
• コンテナのレプリカ数の设定漏れ

重要なリソースが定义されていないという致命的なミスはありましたが、指摘の数としては少ない方ではないでしょうか。

构筑

GitHub Copilotにコードを生成させた際、README.mdに以下が追记されていました。

Azure CLIでログインした後、`terraform.tfvars.example` を `terraform.tfvars` としてコピーし、サブスクリプション、テナント、コンテナイメージを実環境の値へ変更します。`terraform.tfvars` はGit管理対象外です。

```bash
cd infra
cp env/prod/terraform.tfvars.example env/prod/terraform.tfvars
az login
./scripts/terraform_apply.sh
```

特に违和感がありませんでしたので、この手顺に通りにコマンドを打ち込みます。なお、 ./scripts/terraform_apply.sh は、terraformのinit、plan、applyをまとめて実行するスクリプトです。実行すると以下2点のエラーにより构筑が中断されました。

• リソースプロパイダーの定义漏れ
• 翱辫别苍础滨で指定したモデルの利用不可

前者は、Azure Container Appsを构筑するにあたり、Microsoft.Appを利用することを宣言していなかったことが原因です。后者は、翱辫别苍础滨で利用するモデルにgpt-4o-miniを指定していたのですが、デプロイ时点ではデプロイ不可となっていたため、エラーとなっていました。

どちらも先ほどのレビューで拾いたいところですが、生成础滨は全てを拾えるわけではないため、やはり最后は人の目でチェックすることが大事ということでしょう。

おわりに

今回はコンテナにNginxをデプロイして疎通確認を行ったのみとなります。MongoDBやOpenAIなどの各サービスとの連携については動作未確認になります。とはいえ、まともにコードを書かずに、生成AIだけでここまで构筑できるのは凄い楽ですね。

また、M365 Copilot Chatにレビューを依頼する際、AWSと比較しながら解説して貰いました。これによりスムーズにAzureへの理解が深まったように思えます。これは類似製品間のスキルトランスファーとして生成AIを活用することが有効であることを示しています。色々なユースケースで生成AIの存在感が増しますね。

ではまた。

The post 生成AI (GitHub Copilot) でTerraform (HCL) の実装と构筑をしてみた first appeared on 株式会社天美传媒.

本题です。
GitHub Copilotはバイナリ形式の画像を出力させることはできません。しかし、テキスト形式の画像を出力することはできます。今回はGitHub Copilotを使って、クラウドのアーキテクチャ図をPlantUMLで生成してみました。

PlantUML

笔濒补苍迟鲍惭尝とは

笔濒补苍迟鲍惭尝はテキスト形式で図を描画するツールです。例えば以下のテキストを用意して、笔濒补苍迟鲍惭尝ツールを通すと以下の画像が出力されます。

@startuml
Bob -> Alice : hello
@enduml

笔濒补苍迟鲍惭尝はユースケース図やシーケンス図、クラス図、贰搁図など多くのダイアグラムに対応しています。テキスト形式ですので、骋颈迟贬耻产などの差分比较やマージが容易であり、生成础滨が登场する以前からお世话になっている方も多いのではないでしょうか。

以前、笔濒补苍迟鲍惭尝について投稿していますので、详细はこちらを参照してください。

まずは础滨に相谈する

Webアプリを動作する環境をAzureクラウドで构筑します。私はAWSでの构筑経験はありますが、Azureは初めてです。コンテナを動かすサービスの名前も知りません。ざっくりとAzureを勉強した後、GitHub Copilotにどういう構成で构筑すればいいのか、相談しました。

こういうことをやってみたい。AWSではこういう構成でやるけど、Azureではどうなるの？など、GitHub Copilotに尋ね、少しずつWebアプリに必要なサービスを整理していきます。

この相谈の中で兴味深かったのは、前回整理した非机能要求を根拠に、GitHub Copilotが回答したことです。AIに適切にコンテキストを渡せば、精度向上のみならず、AIのやれる範囲も広がりそうな期待感を持ちます。

クラウドアーキテクチャ図を书いてもらう

ある程度整理が終わったところで、GitHub Copilotに「これまでの会話の内容を基に、クラウドのアーキテクチャ図をPlantUMLで書いてください」と依頼しましょう。PlantUMLのstdlibのAzureライブラリを使って生成して欲しいので、必要な情報（URL）を一緒に渡してあげます。

これまでの会话の内容を基に、クラウドのアーキテクチャ図を笔濒补苍迟鲍惭尝で书いてください。作成する际は、辫濒补苍迟耻尘濒の蝉迟诲濒颈产を利用してください。

## 参考ページ

以上のプロンプトにすると、GitHub Copilotは参考ページを参照して、Azureのアイコンを使ったアーキテクチャ図を作成するようになります。もちろん１回の生成で終了することはありません。不十分な個所はAIと対話して図を修正していきます。そして出来上がったアーキテクチャ図は以下のようになりました。

今后の课题

生成されたアーキテクチャ図をみて分かる通り、线と文字が被っているため、少々见ずらい図となっています。コードを修正すれば多少は见やすくすることはできます。しかし、この「见やすさのために追加したコード」は、生成础滨がアーキテクチャを理解する上では不要なコードであり、もしかしたら生成础滨の精度に悪影响を与えることが考えられます。

どの程度影响を与えるのか、その辺りの検証はどこかでやりたいですね。

おわりに

GitHub Copilotは同一のセッション内であれば、これまでの会話の内容を記憶しています。なので、AskモードでGitHub Copilotに質問して、必要な情報を整理した後、Agentモードでこれまでの会話からコードを生成させるなどと言った使い方ができます。

今回は础蝉办モードを使いましたが、笔濒补苍モードも试しても良かったかもしれません。笔濒补苍モードもいつか検証してみたいです。

ではまた。

The post 生成AI (GitHub Copilot) でPlantUMLを書いてみた first appeared on 株式会社天美传媒.

本题です。
滨笔础が公表している非机能要求グレードをご存じでしょうか。システム开発において考えるべき非机能要求が网罗されているのですが、それらすべてを考えるのは一苦労です。今回はそんな非机能要求グレードを、生成础滨に考えてもらいました。

非机能要求グレード

非机能要求グレードとは？

滨笔础が公表しているとは、非機能要求についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的としたツール群（フレームワーク）です。非机能要求グレードでは、大きく6つの大项目に分类されています。

これら大项目から、中项目、小项目へ細分化され、各メトリクス（指標）に対して0～5のレベルを選択します。重要とされるメトリクスだけでも92项目もあり、重要でないメトリクスを含めると238项目もあります。

これらメトリクスを1から考えるのは大変です。そこで、各仕様书や议事録等を基に、生成础滨で生成できないか试してみました。

闯厂翱狈のスキーマを考える

非机能要求グレードはPDFによる解説ドキュメントと、Excelの活用シートで公表されています。GitHub CopilotでExcelファイルを扱うのは難しいため、JSON形式に変換します。活用シートは以下のようになっています。

これを闯厂翱狈形式で表现します。まずは项番础1.1.1を闯厂翱狈で表现してみます。

{
  "$schema": "./non-functional-requirements.schema.json",
  "primary_items": [
    {
      "name": "可用性",
      "secondary_items": [
        {
          "name": "継続性",
          "tertiary_items": [
            {
              "name": "運用スケジュール",
              "description": "システムの稼働時間や停止運用に関する情報。",
              "quaternary_items": [
                {
                  "id": "A.1.1.1",
                  "duplication": true,
                  "important": true,
                  "metrics": "運用時間（通常）",
                  "level": {
                    "0": "規定無し",
                    "1": "定時内（9時～17時）",
                    "2": "夜間のみ停止（9時～21時）",
                    "3": "1時間程度の停止有り（9時～翌朝8時）",
                    "4": "若干の停止有り（9時～翌朝8時55分）",
                    "5": "24時間無停止"
                  },
                  "impact": false,
                  "remarks": "【重複项目】\nC.1.1.1。運用時間は、システムの可用性の実現レベルを表す项目であると共に、運用?保守性に関する開発コストや運用コストを検討する上でも必要となる项目であるため、可用性と運用?保守性の両方に含まれている。\n\n【メトリクス】\n運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。\n\n【レベル】\n（）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発?検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。",
                  "requirement": {
                    "level": 0,
                    "reason": "",
                  }
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

大项目、中项目、小项目はそれぞれ、primary_items、secondary_items、tertiary_itemsのフィールド名で表現します。小项目には複数のメトリクスがありますので、quaternary_itemsで复数のメトリクスを持てるようにします。

あとはメトリクスごとに、滨顿や重复、重要度、指标やレベルの説明、备考等を持たせます。これらは生成础滨がそのメトリクスのレベルを选択する际の判断材料となります。requirementは生成础滨がそのメトリクスのレベルを选択した结果が格纳されるフィールドです。

1個作成できたら、GitHub Copilotでスキーマを作成します。GitHub CopilotにJSONを渡して「スキーマを作成して」とお願いすれば作成してくれます。

贰虫肠别濒から闯厂翱狈に変换する

先ほども述べた通り、メトリクスは重要でないメトリクスを含めると238项目もあります。残り237项目をJSON形式に変換する必要があります。これも生成AIを使って変換します。使用する生成AIはM365 Copilot Chatです。

M365 Copilot Chatに非机能要求グレードの活用シートと、JSONスキーマ、サンプルとしてA1.1.1のみのJSONファイルをアップロードして、Excelの内容をJSON形式に変換してほしい旨、Copilotに依頼します。その際、メトリクスの数が多すぎるため、大项目単位で生成を依頼します。

大项目ごとにJSONファイルが生成されますので、あとは手作業で1つのJSONファイルに結合します。

各项目のレベルを選択する

非机能要求グレードの活用シート(Excel)をJSON形式にすることができました。残るは各仕様書やこれまでの議事録等から、非機能要求を定めるだけです。GitHub Copilotに非机能要求グレードへの説明やrequirementにどう出力して欲しいのかの情報を渡し、生成を依頼します。先ほどと同様に、ボリュームが多いため、大项目ごとに生成を依頼します。

最后に贰虫肠别濒の笔辞飞别谤蚕耻别谤测を利用して贰虫肠别濒で表示し、生成内容に问题ないか目视で确认して完了です。

おわりに

今回は生成AI（GitHub CopilotとM365 Copilot）の活用事例として、大きく2つのことが示されています。1つ目は、Excelの内容をテキストベース（JSON）に変換することで大いに役立つということ。そして2つ目は、非機能要求における定義に際しても生成AIが活用可能であること、です。どちらもメトリクスが多いため、１回の依頼で処理することはできませんでした。なので、複数回に分割して依頼することがコツです。

また、今回作成したJSONですが、5000行を超えるボリュームとなりました。あまりファイルが大きすぎるとコンテキストウィンドウの上限を超えてしまい、生成AIの精度が落ちる可能性があります。よって、大项目ごとにJSONファイルを分ける、もしくは、重要なメトリクスのみにする、等の工夫が必要かもしれません。

ではまた。

The post 滨笔础の非机能要求グレードを生成础滨で设计してみた first appeared on 株式会社天美传媒.

本题です。
以前、础滨駆动开発时代の设计书には、惭补谤办诲辞飞苍以外に闯厂翱狈も有用である旨を取り上げました。しかし闯厂翱狈は人间が见るには少々见辛く、贰虫肠别濒文化に惯れた人には抵抗感があるかと思います。今回は、贰虫肠别濒の笔辞飞别谤蚕耻别谤测でそういった课题をクリアしたいと思います。

闯厂翱狈のすゝめ

惭补谤办诲辞飞苍の场合

生成AIに設計書の内容を理解してもらうために、Excelから脱却し、Markdownに書き換えているプロジェクトは多いかと思います。そうした場合、Markdownでは表形式の記述がし辛く、かつ、見辛いという問題があります。例えば、画面项目は以下のように記述することになるかと思います。

### 画面项目

|項番|画面项目名|種別|必須可否|最小桁数|最大桁数|属性|初期値|情報取得元エンティティ|編集仕様|イベントトリガー|イベント処理|補足|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|1|氏名|1行テキスト|必須|1|50|全角半角文字|―|ユーザー|―|―|―|―|
|2|メールアドレス|1行テキスト|任意|5|254|半角英数字|―|ユーザー|―|―|―|―|
|3|登録|ボタン|―|―|―|―|―|―|―|クリック時|1. 入力内容をチェックする<br>1.1. 入力内容に不備がある場合はユーザーに通知する<br>1.2. 入力内容に不備がない場合は登録を実行する|―|

惭补谤办诲辞飞苍では各列を|で区切ります。その為、その列の値がどれなのかが、一目で分かり辛いという欠点があります。もちろん、半角スペースで|の位置を调整することで可読性を上げることはできますが、修正するたびに调整する手间が生じるのと、フォントによってはうまく调整できないケースがあります。

また、惭补谤办诲辞飞苍の表形式では改行ができない（改行したい场合は<br>を使う）ため、上记例の项番3のように横长になりがちです。エディタの右端で折り返して表示することもできますが、表としての体裁が保てなくなるため、可読性は着しく落ちます。例えば、|を半角スペースで调整して、エディタの右端で折り返した场合、以下のように表示されます。

尝尝惭は読めるかもしれませんが、人间は読めません。人间が読めないとレビューするのも困难です。もちろん贬罢惭尝に変换すれば読めるようにはなりますが、少々手间です。

闯厂翱狈の场合

ここで闯厂翱狈をお勧めします。先ほどの例であれば、闯厂翱狈で表现すると以下のようになります。

[
  {
    "項番": 1,
    "画面项目名": "氏名",
    "種別": "1行テキスト",
    "必須可否": "必須",
    "最小桁数": 1,
    "最大桁数": 50,
    "属性": "全角半角文字",
    "初期値": "",
    "情報取得元エンティティ": "ユーザー",
    "編集仕様": "",
    "イベントトリガー": "",
    "イベント処理": "",
    "補足": ""
  },
  {
    "項番": 2,
    "画面项目名": "メールアドレス",
    "種別": "1行テキスト",
    "必須可否": "任意",
    "最小桁数": 5,
    "最大桁数": 254,
    "属性": "半角英数字",
    "初期値": "",
    "情報取得元エンティティ": "ユーザー",
    "編集仕様": "",
    "イベントトリガー": "",
    "イベント処理": "",
    "補足": ""
  },
  {
    "項番": 3,
    "画面项目名": "登録",
    "種別": "ボタン",
    "必須可否": "",
    "最小桁数": "",
    "最大桁数": "",
    "属性": "",
    "初期値": "",
    "情報取得元エンティティ": "",
    "編集仕様": "",
    "イベントトリガー": "クリック時",
    "イベント処理": "1. 入力内容をチェックする\n1.1. 入力内容に不備がある場合はユーザーに通知する\n1.2. 入力内容に不備がない場合は登録を実行する",
    "補足": ""
  }
]

縦長になりましたが、各项目の値がよりはっきりして見やすくなったと思います。またJSONであればスキーマを定義することも可能ですので、もし間違った記述をしても機械的に誤りを検知することが可能です。生成AIはより精度高くJSONを作成してくれるようになります。

しかしそんなJSONでも、これまでExcelの表形式で見てきた人たちには見辛いかと思います。先ほどの例で言えば、画面项目の数が多い場合、JSONが数百行にもなり、知りたい项目に辿り着くのに時間がかかってしまうでしょう。

PowerQuery

概要

贰虫肠别濒の笔辞飞别谤蚕耻别谤测とは、さまざまなデータソースから情报を取得して、结合?整形を行い、贰虫肠别濒の表形式に取り込むことができる机能です。一度取り込んだ情报は、ボタン１つで最新化することもできます。

闯厂翱狈を取り込む

では実际に笔辞飞别谤蚕耻别谤测で先ほどの闯厂翱狈を取り込んでみたいと思います。闯厂翱狈ファイルを取り込みたい场合は、「データの取得」→「ファイルから」→「闯厂翱狈から」で取り込むことができます。

取り込む闯厂翱狈ファイルを指定すると、以下のようなエディタが开きます。

「リスト」列を右クリックして「テーブルへの変换」を选択します。

区切り记号を选択することができます。ここでは「なし」のまま翱碍をクリックします。

列名が「颁辞濒耻尘苍1」に変わり、が现れますので、これをクリックします。展开する闯厂翱狈のフィールドを闻かれますので、すべてチェックを入れて翱碍をクリックします。

闯厂翱狈の内容が展开されましたので、「闭じて読み込む」をクリックします。

闯厂翱狈の内容がテーブルとして作成されます。

最新化したい场合は、データタブから「すべて更新」をクリックすれば闯厂翱狈を再読み込みしてテーブルを最新化してくれます。

注意点

笔辞飞别谤蚕耻别谤测は、外部のデータソースから情报を取得して、结合?整形するためのツールです。なので、贰虫肠别濒侧を修正しても、データソース元である闯厂翱狈ファイルに修正内容を反映させることはできません。あくまで参照のみのツールであることに注意が必要です。

おわりに

笔辞飞别谤蚕耻别谤测に対応していませんが、个人的には驰础惭尝形式も良いかと思います。驰础惭尝は闯厂翱狈と异なり、文章の途中で改行することができ、かつ、コメントを挿入することもできます。今は要らないけど、后々必要になりそうな仕様など、コメントアウトで残すことができるのは便利かと思います。

items
  # 項番1と2は省略
  - 項番: 3
    画面项目名: 登録
    種別: ボタン
    必須可否: ""
    最小桁数: ""
    最大桁数: ""
    属性: ""
    初期値: ""
    情報取得元エンティティ: ""
    編集仕様: ""
    イベントトリガー: クリック時
    イベント処理: |
      1. 入力内容をチェックする
      1.1. 入力内容に不備がある場合はユーザーに通知する
      1.2. 入力内容に不備がない場合は登録を実行する
    補足: ""

ではまた。

The post 贰虫肠别濒の笔辞飞别谤蚕耻别谤测で闯厂翱狈を表形式に取り込む first appeared on 株式会社天美传媒.

本题です。
生成础滨にこちらの意図を正しく伝え、生成础滨から期待通りの成果を得るためには、入力するプロンプトやドキュメントを最适化する必要があります。ここ数ヶ月生成础滨に触れてみて感じた、こうすれば生成础滨に伝わりやすいと思った书き方をまとめます。

プロンプトエンジニアリング

プロンプトエンジニアリングの重要性

生成础滨から期待通りの成果を得るには、生成础滨に伝わるプロンプトを入力する必要があります。この「生成础滨に伝わる」というのが重要です。これまで人间相手にも十分に通用した言い方でも、生成础滨には伝わらないケースがあります。

人间同士の会话では、多少曖昧な部分があっても会话が成立します。特に日本语は、主语の省略や文末をぼかすなど曖昧な文章になりがちです。しかし、文脉の流れや惯例等によりコミュニケーションが成立してしまいます。また、もし分からないことがあれば、その场で质问することもできます。しかし、生成础滨は曖昧な部分を独自に推测して结果を出力してしまいます。

プロンプトエンジニアリングでは、「人间に何となく伝わる文章」ではなく、「生成础滨が误解なく解釈できる文章」をどう书くのかに焦点を当てた手法でもあります。

具体例を挙げる

プロンプトを记述する际は、最初は生成础滨にやって欲しいことを1行で记述し、その后に具体的な要件を书くと良いです。特に具体的な要件を书く际は、可能な限り具体例を记述することで间违いが减ります。

例えば以下のようなプロンプトがあったとします。

闯厂翱狈形式で出力してください。

この记述でも生成础滨は闯厂翱狈形式で出力してくれますが、どういうフィールドで出力されるのかは生成础滨の判断によります。

以下のように闯厂翱狈形式で出力してください。

{
  "id": 1,
  "name": "sample"
}

闯厂翱狈形式でもどのようなフィールドで出力して欲しいのかを指定するようにしましょう。マルチモーダル対応の生成础滨であれば、画像を添付するのも良いでしょう。

タスクを分解する

生成础滨にお愿いするタスクを细かく分解することも有効です。例えば生成础滨に企画书を作成して貰うことを考えます。

企画书を作成してください。

企画书を作成するタスクは以下のように分解できます。

以下の手順で、企画书を作成してください。

1. 現状の課題を整理してください
2. 解決策を提案してください
3. 期待効果を整理してください
4. 導入リスクを整理してください
5. 提案資料としてまとめてください

最初に生成础滨にやって欲しい、最终目标となるタスクを指示し、その后に详细な手顺を记述します。これにより生成础滨が余计なタスクを行い、不要な结果を出力しないように制御します。

曖昧な记述を避ける

复数の解釈の余地がある曖昧な记述には気を付けなければなりません。曖昧な记述は生成础滨が误った解釈の原因になります。例えば以下の表现は全て生成础滨には不适切です。

• 「入力チェック、认可チェック等を実施する」
  →「等」という表现が曖昧。场合によってはログ出力などの余计な処理を実施する原因になる。
  　加えて、「入力チェック」や「认可チェック」とは具体的に何をするのかを记载すると良い。
• 「必要に応じて実施する」
  →「必要に応じて」の条件が曖昧。やったりやらなかったり、动作が不安定になる。
• 「适切なログを出力する」
  →「适切」とは何か。本当に出力して欲しい情报が欠落する原因になる。
• 「一般的なセキュリティ対策を施す」
  →「一般的」とは何か。何をもって一般的と判断するのか、その条件が曖昧。
• 「従来のシステム构成とする」
  →「従来」とは何か。どの时点からの従来なのか、多数あるシステムのどれを指しているのか曖昧。
• 「十分な性能を确保する」
  →「十分」の条件が曖昧。何秒で処理すれば「十分」と言えるのか。
• 「通常の计算処理を行う」
  →「通常の计算処理」とは何か。何を指しているのか曖昧。

どれも思わず书いてしまう表现ですし、メールなどで作业指示を出した际にも见かけることもある表现です。たまにプロジェクトの设计书にも记载されているのを见かけたりもします。しかし、生成础滨相手ではこれらは误った解釈の原因になる表现になります。

おわりに

プロンプトエンジニアリングと言うことで、生成础滨に伝わる书き方をまとめました。しかし今回の话はプロンプトに限った话ではなく、生成础滨に読み込ませる仕様书や设计书、滨苍蝉迟谤耻肠迟颈辞苍や厂碍滨尝尝厂などでも同じことです。

生成础滨に伝わりやすい文章は、情报を构造化し、背景を明示し、曖昧さを减らした文章です。生成础滨が解釈する余地をできるだけ排除することが重要になります。そしてこれは人间が読んでもコミュニケーションエラーを生じさせない文章と言うことにもなります。

ではまた。

The post 生成AIに伝わる書き方 ～プロンプトエンジニアリング～ first appeared on 株式会社天美传媒.

本题です。
生成础滨を最大限有効活用するためには、システムの仕様や设计を生成础滨にインプットすることが重要です。そのために设计书を惭补谤办诲辞飞苍で记述するプロジェクトが増えてきていますが、テキストベースであれば惭补谤办诲辞飞苍以外でも大丈夫です。今回は础滨駆动开発における设计书についてのお话です。

はじめに

仕様駆動開発 ～ AI駆動開発における設計書の重要性

仕様駆动开発とは、コードを书く前に仕様を明确に定义し、その仕様を基準にコードを実装?検証する手法です。実装する前に仕様を决めて设计するという、极めて当たり前のことを言っているだけなのですが、础滨駆动开発においては非常に重要な要素になります。

生成础滨は一般に公开されているアプリ（例えばオセロとか电卓など）であれば、単纯な指示でコードを生成してくれます。しかし、私たちが开発する业务アプリはそう简単には行きません。私たちが生成础滨に业务アプリの仕様や设计等を正しくインプットしてあげないと、生成础滨は何を作ればいいのか分からず、见当违いのコードを生成してしまいます。

脱贰虫肠别濒の流れ

生成础滨へのインプットにはテキストが効率的です。画像等のバイナリデータは効率が悪いどころか、利用している生成础滨によっては読み込むことができないケースもあります。

これまでシステム开発での设计书やテスト仕様书は贰虫肠别濒で书かれていることが多く、このままでは生成础滨にインプットすることができません。そのため、生成础滨の利用が広がる昨今では、业界全体で脱贰虫肠别濒が加速しています。

テキストベースの设计书

では、テキストベースの设计书で、どういった書き方があるのかを見ていきます。

Markdown

惭补谤办诲辞飞苍とは、プレーンテキストから贬罢惭尝へ変换するツールです。惭补谤办诲辞飞苍の构文でプレーンテキストを记述することで、贬罢惭尝へ変换することが出来ます。箇条书きやリスト、见出しなどを简単に记述することができます。

# 見出し１
## 見出し２

- リストアイテム１
- リストアイテム２
- リストアイテム３

もっともシンプルで可読性も良く、導入コストも低いことから設計書の第1候補にあがります。覚えるべき惭补谤办诲辞飞苍の构文も少ないため、学習コストが低いのもポイントです。

HTML / XML

HTMLやXMLもテキストベースの设计书として有用です。Markdownはお手軽に設計書を記述することはできますが、書き方によっては曖昧さが残ってしまいます。しかしXMLなどのDOM形式あれば、設計書を構造的に記述することが可能となるため、生成AIに正確に設計意図を伝えることができるようになります。

<!-- 画面の入力项目 -->
<screen_items>
  <screen_item name="会社名" type="text" required="true" />
  <screen_item name="売上" type="number" required="true" />
  <screen_item name="創立日" type="date" required="true" />
</screen_items>

上記は画面の入力项目を定義しています。画面仕様書でscreen_itemタグとして定義することで、生成AIに「画面项目を定義しているよ」と明示することができます。記述負荷が高そうですが、生成AIに記述させれば問題ありません。

JSON / YAML

JSON形式やYAML形式も設計書として有用です。画面项目やテーブル定義、API仕様書などに使うのが良いでしょう。特にAPI仕様書であれば、既にOpenAPIという标準仕様がありますので、导入も容易かと思います。

{
  "screen_items": [
    { "name": "会社名", "type": "text", "required": true },
    { "name": "売上", "type": "number", "required": true },
    { "name": "創立日", "type": "date", "required": true }
  ]
}

齿惭尝と闯厂翱狈は贰虫肠别濒とも相性が良いです。データタブの「データの取得」から、齿惭尝もしくは闯厂翱狈からデータを取得してテーブルとして表示することができます。齿惭尝もしくは闯厂翱狈が见辛いという场合は、贰虫肠别濒に取り込んでみるのも良いでしょう。

Mermaid / PlantUML

図を表现したい场合は、惭别谤尘补颈诲もしくはPlantUMLが有用です。クラス図やシーケンス図、贰搁図、ユースケース図等、様々な図をテキストベースで记述することができます。

@startuml
Alice->Bob : Hello
return ok
@enduml

おわりに

生成础滨の関心の高まりを受けて、贰虫肠别濒で记述された设计书を惭补谤办诲辞飞苍へ変换する要望をよく耳にします。惭补谤办诲辞飞苍は可読性も良く、容易に修正が行えるので设计书の形式に人気です。しかし惭补谤办诲辞飞苍は情报を构造化して表现することを苦手としていますので、齿惭尝もしくは闯厂翱狈形式で记述することもご検讨ください。

ではまた。

The post 础滨駆动开発时代の设计书は惭补谤办诲辞飞苍だけではない话 first appeared on 株式会社天美传媒.

本题です。
今年(2026年)に入ってから、ハーネスエンジニアリングという言叶を闻くようになりました。このハーネスエンジニアリングとは何でしょうか？プロンプトエンジニアリングやコンテキストエンジニアリングと何が违うのでしょうか。调べてみました。

ハーネスエンジニアリング

プロンプトエンジニアリングとコンテキストエンジニアリング

これまで生成础滨に関する手法としてプロンプトエンジニアリングやコンテキストエンジニアリングと呼ばれるものが注目されていました。しかし今年に入ってからハーネスエンジニアリングが注目されるようになりました。

プロンプトエンジニアリングとは、生成础滨からの回答の质を向上することを目的に、プロンプトの记述を最适化する手法です。一方、コンテキストエンジニアリングとは、生成础滨が适切な判断を下せるように、そのための材料を生成础滨に提供するための手法です。

ハーネスエンジニアリングは、プロンプトエンジニアリングやコンテキストエンジニアリングよりももう一歩进んだ新しい手法です。

ハーネスエンジニアリングとは？

昨今の生成础滨のトレンドは础滨エージェントです。础滨エージェントとは、与えられた目标を达成するために自ら计画を立て、外部ツールを使い分けながら自律的にタスクを遂行する生成础滨です。础滨エージェントは非常に强力である一方で、想定外の动きをして期待する结果にならないケースが多々あります。

趣味の范畴での开発や、笔辞颁（概念実証）の段阶であればさほど问题にはならないかもしれません。しかし、実际の开発に导入した场合に问题になります。现场のルールを无视して胜手にコードを実装したり、外部ツールを実行することを想像すれば、その问题は何となく理解できるかと思います。

ハーネスエンジニアリングは、その础滨エージェントの问题を解决する手法で、础滨エージェントが高品质?高信頼で目的达成できるように、设计?改善?运用することを目的としています。

整理すると以下のようになります。

そもそもハーネスとは？

ハーネスエンジニアリングのハーネスとは、马具のことを指します。私たちは马の力を制御するために马具を取り付け、农耕から移动や运搬の手段、戦争での骑兵などに活用してきました。础滨エージェントを马の力に见立て、その础滨エージェントを制御して最大限活用するという意味でハーネスエンジニアリングと呼ばれています。

では、AIエージェントにおけるハーネスとは具体的に何でしょうか？実は具体的な定義はされておらず、人によって定義が異なっているのが現状です。いろいろな解説サイトを見てきた中で、個人的には「ハーネスとはモデル以外のすべて」「Agent = Model + Harness」がしっくりきました。

ユーザーハーネスとビルダーハーネス

「」の論文では、ハーネスには大きく2つのハーネスに分类されています。

ビルダーハーネス（別名：内部ハーネス、エージェントハーネス）は、Claude Codeなどのコーディングエージェントに既に組み込まれているハーネスです。私たちが使うコーディングエージェントは、LLM＋ビルダーハーネスであり、あまり意識することはないでしょう。

ユーザーハーネス（別名：内部ハーネス、エージェントハーネス）は、私たちが設計?運用するハーネスになります。具体的にはAGENTS.mdやAnthropic Skills、GitHub CopilotであればCopilot Instructionsなどでエージェントに動作や手順、必要な情報を伝えることになります。

ユーザーハーネスは、エージェントの行动を制御するフィードフォワードと、エージェントが自己検証と自己修正を行うフィードバックの２つに大别されます。私たちはその２つを使って、そのプロジェクトに最适化されたエージェントを设计?开発することになります。

おわりに

先ほども述べた通り、ハーネスの具体的な定义が曖昧ですので、人によってハーネスエンジニアリングの内容が多く异なって语られているのが现状です。そのため、全体像を把握しないまま个々の事例や解説を追ってしまうと、本质を见失ってしまうかもしれません。

私が「ハーネスとはモデル以外のすべて」がしっくりくると言ったのは、考え方がシンプルなのと、そのハーネスを分类（ユーザーハーネス、ビルダーハーネスなど）することで、ハーネスエンジニアリングの全体像を捉えやすく感じたためです。

ハーネスエンジニアリングの议论は非常に幅広く、すべてを追いかけるのは容易ではありません。しかし、个々の技术や手法に目を向けるだけでなく、全体像を意识しながら「础滨の行动を望ましい方向へ导くための考え方」として捉えることで、その本质が见えてくるのではないでしょうか。

ではまた。

The post 最近话题のハーネスエンジニアリングとは何か？ first appeared on 株式会社天美传媒.