みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 新しいワークショップ Accelerating Smart Product SDLC with AI Agent Workshop Lab4 をリリースしました。このワークショップは、Kiro を SDLC (ソフトウェア開発ライフサイクル) 全体に活用し、HVAC (空調) 制御システムを題材に Kiro を用いた組込ソフトウェアやライフサイクルの長いソフトウェア開発への適用を実証します。新しい生成 AI の開発プロセスを学びたい方にお勧めです。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年3月2日週の主要なアップデート 3/2(月) AWS Config が 30 の新しいリソースタイプをサポート AWS Config が 30 種類の新しいリソースタイプをサポートしました。Amazon Bedrock AgentCore や Amazon Cognito などの主要サービスが対象で、これまで監視できなかったリソースも含まれています。すでに全リソースタイプの記録を有効にしている場合は、自動的に新しいリソースも追跡されるため、追加設定は不要です。Config ルールや Config アグリゲータでも利用でき、より包括的なクラウド環境の監視と管理が実現できます。 AWS Batch でスケールダウン遅延の設定が可能になりました AWS Batch でスケールダウンの遅延時間を設定できるようになりました。従来はジョブ完了後すぐにインスタンスが終了していましたが、新しい minScaleDownDelayMinutes パラメータで 20 分から 1 週間まで稼働継続時間を指定可能です。今回のアップデートで、しばしば発生していたバッチ処理を行う際に、インスタンス起動待ちを削減でき、処理時間の短縮につなげられます。詳細は こちらの API ガイドをご参照ください。 3/3(火) Amazon SageMaker Unified Studio が Kiro IDE からのリモート接続サポートを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモート接続サポートが開始されました。これまでローカル IDE とクラウドインフラの間で作業環境を切り替える必要がありましたが、今回のアップデートにより Kiro の AI 機能を使いながら SageMaker のスケーラブルな計算リソースに直接アクセスできるようになります。データサイエンティストや ML エンジニアは使い慣れた開発環境を維持しつつ、クラウドの強力なリソースを活用した効率的な開発が可能です。詳細は こちらのドキュメントをご参照ください。 Amazon SageMaker Unified Studio が AWS Glue 5.1 をサポートし、データ処理ジョブが可能に Amazon SageMaker Unified Studio が、Visual ETL、ノートブック、およびコードベースのデータ処理ジョブにおいて AWS Glue 5.1 をサポートするようになりました。Apache Spark 3.5.6 や Python 3.11 などの最新バージョンが使えるようになり、Apache Iceberg や Delta Lake といったオープンテーブルフォーマットライブラリも更新されています。データエンジニアやデータサイエンティストは、Visual ETL やノートブックジョブで最新の機能を活用でき、データ処理パフォーマンスの向上が期待できます。詳細は こちらのドキュメントをご参照ください。 3/4(水) Amazon OpenSearch Ingestion が OpenTelemetry データ用の統合取り込みエンドポイントをサポート Amazon OpenSearch Ingestion で OpenTelemetry の統合エンドポイントがサポートされました。従来はログ、メトリクス、トレースの 3 種類のデータを処理するために 3 つの別々のパイプラインが必要でしたが、今回のアップデートで 1 つのパイプラインで全てを処理できるようになりました。また、段階的に OpenTelemetry を導入する際も、パイプラインの再設定なしで新しいシグナルタイプを追加できるため、導入の柔軟性が向上します。詳細は こちらのドキュメントをご参照ください。 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンクとしてサポート開始 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンク (データの書き込み先) としてサポートし、マネージド型のメトリクス取り込みパイプライン構築が簡単になりました。従来必要だったパイプラインの構築作業を削減でき、ログ、トレース、メトリクスを同一パイプラインで統一管理できます。ログは OpenSearch Service に、メトリクスは Prometheus に送信し、各サービスの強みを活かした observability 環境を構築できます。詳細は こちらのドキュメントをご参照ください。 Amazon Lightsail が OpenClaw (プライベートなセルフホスト型 AI アシスタント) を提供開始 Amazon Lightsail で OpenClaw をワンクリックデプロイできるようになりました。サンドボックス分離、自動HTTPS、デバイス認証、自動バックアップといったセキュリティ機能が最初から組み込まれており、デフォルトの LLM プロバイダーとして Amazon Bedrock が統合されています。Slack・Telegram・WhatsApp・Discord への接続やモデルの切り替えも可能で、東京を含む15リージョンで利用できます。詳細は クイックスタートドキュメント ページをご覧ください。 AWS がサービスワークフロー内での IAM ロール作成とセットアップを簡素化 AWS IAM で、各種サービスのワークフロー内で直接 IAM ロールを作成・設定できるようになりました。従来は IAM コンソールに移動してロールを作成する必要がありましたが、EC2 や Lambda などのサービス画面内で権限設定まで完結できるため、作業効率が大幅に向上します。現在バージニア北部リージョンで提供開始され、他のリージョンにも順次展開予定です。 3/5(木) 新しい Kiro パワーで Lambda 永続関数開発を加速 AWS が Lambda durable functions の Kiro power を発表しました。これにより、Kiro IDE や Kiro CLI 上の開発環境で、長時間実行される複雑なワークフローを簡単に構築しやすくなります。注文処理や支払い調整など複数ステップが必要な処理を、AI エージェントのサポートを受けながら効率的に開発可能です。詳細は こちらの developer guide をご参照ください。 Amazon Connect Health の紹介、ヘルスケア向けに構築されたエージェント AI mazon Connect Health が一般提供開始されました。医療機関向けの AI エージェントサービスで、患者確認、予約管理、診察前の患者インサイト表示、診察中のアンビエント文書化、診察後の ICD-10・CPT コード自動生成など、診療業務全体を効率化します。自然言語での音声対話による 24 時間 365 日の予約受付や、EHR 記録とのリアルタイム照合による本人確認にも対応しています。現在バージニア北部とオレゴンリージョンで利用可能です。 Database Savings Plans が Amazon OpenSearch Service と Amazon Neptune Analytics をサポート開始 Database Savings Plans が新たに、 Amazon OpenSearch Service と Amazon Neptune Analytics に対応しました。これまでは RDS などの一部データベースサービスのみが対象でしたが、今回の拡張により検索エンジンサービスやグラフデータベース分析にも適用可能になります。1 年間のコミットメント (前払いなし) で最大 35 % のコスト削減が実現でき、インスタンスタイプを変更してもプランが自動適用される柔軟性もあります。詳細は こちらの pricing page をご参照ください。 3/6(金) Amazon Redshift が COPY オペレーション用の再利用可能なテンプレートを導入 Amazon Redshift で COPY コマンドのテンプレート機能が提供開始されました。COPY コマンドは、S3 などの外部データソースからRedshiftのテーブルに大量のデータを一括ロード（取り込み）するためのコマンドです。これまで COPY 操作のたびに手動でパラメータを指定する必要がありましたが、頻繁に使用するパラメータを事前にテンプレートとして保存し再利用できるようになります。ファイル形式やデータソースごとに標準設定を作成でき、チーム間での一貫性確保やヒューマンエラー削減、運用効率向上につながります。詳細は こちらの Blog 記事をご参照ください。 Amazon Redshift が半構造化データ処理のための新しい配列関数を導入 Amazon Redshift で、JSON などの半構造化データを格納できる SUPER データを操作するための 9 つの新しい配列関数をサポートするようになりました。新しい関数を利用することで、ARRAY_CONTAINS や ARRAY_SORT など、配列の検索・比較・並び替え・変換を SQL クエリーで実現できます。従来は複雑な PartiQL ロジックが必要だった操作が、単一の SQL 文で簡単に処理できるようになり、よりシンプルに利用できるようになりました。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

対象読者 copilot-instructions.md や SKILL.md をすでに書いていて、ある程度動かせている人 「毎回同じ指示を繰り返してるな」と薄々気づいている人 Instructions / SKILL をもっと賢くしたいが、何をどう変えればいいか分からない人 Agent Skills の基本（ディレクトリ構造、SKILL.md の書き方）は「 【2026年版】Agent Skills 入門 」を、設定ファイルの全体像は「 GitHub Copilot の設定ファイル5種 」を参照してください。 チャットの履歴にすべて答えがある ども！龍ちゃんです。 僕は普段、Claude Code と GitHub Copilot を用途に応じて使い分けていて、セッションの長さや制限状況によって切り替える感じで運用しています。両方使い込んでいくと気づくことがあって、 セッションをまたいで同じ指示を繰り返してる自分 に気づくんですよね。 「このプロジェクトでは uv を使ってるので〜」とか、「コミットメッセージは日本語で〜」とか。モデルが変わっても関係なく、自分の癖として毎回同じことを最初に説明してしまっています。 んで気づいたときに設定ファイルだったり、SKILL化したりしています。 ただ忙しいときって、時間をとって分析しようとはなかなかならないんですよね。日常の開発を止めてまでやることでもないし、「まあこんなもんかな」で流してしまう。 でも、そういう「こんなもんかな」が積み重なると、毎回毎回同じ摩擦が続くことになります。一発でそのループを断ち切りたい、というのが今回の話の出発点です。 この記事では、チャット履歴から改善点を見つけて copilot-instructions.md / SKILL.md に反映する具体的なフローを紹介していきますね。 今回の内容です。 チャット履歴から改善点を見つける3つの方法 方法ごとの使い分けと、それぞれの特性 見つけた改善点を Instructions と SKILL.md にフィードバックするフロー チャット履歴から改善点を見つける3つの方法 3つの方法を紹介します。「UI で見返す」「セッション内でポストモーテムする」「エクスポートして横断分析する」と、だんだん深掘りが増えていく構成です。どれか1つだけやるというより、状況に応じて使い分けるイメージで見てもらえると。 方法1: VS Code の UI でチャット履歴を見返す 一番シンプルな方法です。Copilot の UI でセッションを行き来して、「自分が何を言ってたか」を見返すだけですね。 GitHub Copilot はチャット履歴が UI 上で見えるので、過去のセッションに遡りやすいのが利点です。「先週のあのやりとり」みたいな感じで、セッション間を移動しながら確認できます。どういう変更が加えられたか、自分がどう指示したかを単純に追いたいときはこれが一番手軽です。 まずこれだけでもやる価値があるんですが、「セッション横断でパターンを見つける」という目的には正直向いてないですね。次の方法がそこをカバーします。 方法2: セッション内で lessons ファイルにまとめる（ポストモーテム） 僕が Claude Code で一番使っている方法で、GitHub Copilot でも同じようにできます。 やり方はシンプルで、 セッション中に意図と違う挙動が起きて、修正が終わったタイミングで振り返る ことです。「なぜこう解釈したのか」「自分はこう意図したけど伝わらなかったのはなぜか」をそのセッション内で詰めていきます。 Copilot に投げかけるのはこういう感じです： この問題をまとめて lessons に入れて なんでこうなった？ 次どうする？ 正直わりとパワハラ気味に詰める感じなんですが、この詰めが大事で。原因と対策をセットで残してもらうことが目的です。 lessons/2026-03-04.md のようなファイルが生成されて、再発防止策のドキュメントが溜まっていきます。 AI コーディングエージェントを使ったポストモーテム（ふりかえり） 、というイメージで使っています。（んでもちろん自分の入力が悪いと顧みるときもあります…） この方法のカバー範囲は「そのセッション内で気づいた問題」なんですよね。セッションをまたいだパターン、たとえば「3週間ずっと同じ前提を最初に説明してた」みたいなことは気づけません。それが次の方法です。 方法3: チャットエクスポートでセッション間の横断分析 ここが記事の本題です。GitHub Copilot ならではの手法なんですよね。 VS Code には「 Chat: Export Chat… 」という機能があって、セッションを JSON データとしてダウンロードできます。この JSON には、自分がどう指示して、AI がどういう挙動をしたかまでセットで入っているんですよね。 エクスポートの手順はこうです。 VS Code で Copilot Chat パネルを開く コマンドパレット（ Ctrl+Shift+P / Cmd+Shift+P ）を開く 「 Chat: Export Chat… 」を選択 保存先を指定 → JSON ファイルが出力される 操作自体はこれだけです。ただ、出力される JSON はそのまま読める量じゃないんですよね。6ターンの会話で 20,000行超になったりします。この変換の話はあとで出てきます。 1週間分まとめてエクスポートして、全セッションを横断的に分析すると、 セッションをまたいで共通するパターン が見えてきます。そのパターンが、Instructions や SKILL 化の目処になっていく感じです。 ここで少し前振りを入れておくと、Claude Code も拡張機能を使えばチャット履歴は見れます。ただ、GitHub Copilot はいろんなモデルを切り替えながら使えるので、 モデルごとの差分が出るのが面白い んですよね。同じ指示をしても、claude-sonnet-4.5 と GPT-5-mini では挙動が違ったり、Thinking の詳細度が変わったりします。その差分もエクスポートデータに残るので、「このモデルはこういう指示の方が伝わりやすい」みたいな知見が蓄積されていきます。 エクスポートデータを使った横断分析の実践 ここからは方法3の具体的な分析フローです。 まず、エクスポートした JSON をそのまま分析しようとすると、6ターンの会話が 20,000行超の JSON になっているので人間が読むのは無理なんですよね。前の記事で紹介した copilot-chat-converter を使って Markdown に変換すると一気に読みやすくなります（20,000行 → 720行くらいに）。 このあたりの変換手順は前の記事「 Copilot Chat の会話履歴を Markdown で保存するパイプラインを作った話 」で詳しく書いているので、そちらも見てみてください。 変換した Markdown を1週間分並べて、AI に投げます： この1週間のチャット記録を分析して。 セッションをまたいで繰り返し出てくる指示パターンがあれば抽出して。 対象：自分が Copilot に毎回同じ前提を説明している箇所、手動で繰り返している手順。 自分で分析しても構いませんが、AI に任せた方が速いですね。人間が見るだけでは「なんとなく同じことを言ってるな」で終わってしまうところを、パターンとして整理してもらえます。 僕が実際に分析して見つかったパターンの話をすると、一番驚いたのが SKILL の description 問題でした。 あるスキルが全然発火しないので何度も「スキル使って」と手動で言い直していたんですよね。この繰り返しがログに残っていたので、「なんでこのスキルだけ発火しないんだろう」と原因を掘り下げたら、 description: | （YAML の複数行記法）が原因だと分かって。複数行記法だと各行が別の属性として誤解釈されて、description が空になってしまうという問題でした。 「 Claude CodeからGitHub Copilotへ移植したらAgent Skillsが動かない？原因と解決策 」で検証結果と回避策を詳しく書いているんですが、ざっくり言うと description: "..." の単一行に書き直すだけで解決しました。この問題、横断分析しなかったら「なんか発火しにくいな」で終わっていたと思います。ログがあって、繰り返しパターンとして可視化されたから気づけた体験でした。 他にも「プロジェクトで使用できるCLIツール」という前提を毎回説明していたことも見つかりました。これも横断で見ないと気づきにくいんですよね。セッション単体では「毎回説明するのが当たり前」になっていて、問題と認識していなかったので。 方法2と方法3の使い分けを整理するとこうです。 方法2（lessons ポストモーテム） 方法3（エクスポート横断分析） 対象 セッション内の問題 セッション間の繰り返しパターン タイミング 問題が起きた直後 定期的（週1など） 主な発見 「なぜこの挙動が起きたか」 「毎回同じ摩擦が起きている」 見つけた改善点を Instructions と SKILL.md にフィードバックする 方法1〜3で見つけたパターンを、どう Instructions / SKILL.md に落とし込むかです。 SKILL テスト → ログ → フィードバックのサイクル 僕が一番使っているのが、 SKILL 構築のテスト結果をログとして残してフィードバックするサイクル です。 SKILL を作ったら、まずテストします。そのとき「うまく発火しない」「意図と違う挙動が出る」ことは結構あるんですよね。その結果を lessons ファイルに残して、ログを見ながら SKILL.md の description や手順を修正して、再テストして改善を確認する、というサイクルを回します。 さっきの description の | 問題がまさにこのサイクルの産物で、テストで発火しないことを確認 → ログに残す → 原因を特定（ description: | の複数行記法） → 単一行 description: "..." に修正 → 再テストで発火を確認、という流れで解決しました。 このサイクルが回り始めると SKILL の精度がどんどん上がっていくんですよね。最初は「なんか動く」レベルでも、繰り返すうちに「言えば確実に動く」に変わっていきます。 SKILL.md の書き方の基本は「 【2026年版】Agent Skills 入門 」に詳しくまとめているので、まだ読んでいない方はそちらから。 繰り返し指示 → copilot-instructions.md に集約 SKILL テストの過程でも、「毎回同じ前提を説明してる」パターンは見つかります。モデルに関係なく同じ指示を繰り返していたなら、それは copilot-instructions.md に1行追加するだけで以降の暗黙の前提にできます。 さっきの「使用できるCLIツールは~~」の例なら、instructions に書いてしまえばセッションの最初に説明しなくて済むようになります。 copilot-instructions.md と AGENTS.md の使い分け（どちらに書くべきか、スコープの違い）については「 copilot-instructions.md と AGENTS.md の使い分け 」で整理しているので参考にしてみてください。 手動ワークフロー → SKILL.md 化 複数のセッションで同じ手順を説明していたら、SKILL 化の候補です。 前の記事で紹介した copilot-chat-converter （JSON → Markdown 変換ツール）も、最初は「このコマンドを実行して、出力はここに保存して」と毎回説明していたんですよね。横断分析でその繰り返しに気づいて、SKILL.md に落とし込んで「チャット変換して」の1行で動くようにしました。 また、チャット内で便利なコードを作ってもらってそこからそのやっていることをエクスポートとしてCLIツールに昇華したりSKILLとしてまとめたりしています。 「手順の説明を何回かやったな SKILL にするか～」くらいの感覚でやってます。 まとめ：「3回繰り返したら仕組みにする」 ここまでの流れをまとめると、こういうサイクルです。 シンプルなルールとして意識しているのは、 「同じ指示を3回したら Instructions に書く」「手順を3回説明したら SKILL にする」 ということですね。最初から完璧を目指さなくていいんですよ。気づいたときに1つ直す、の積み重ねでどんどん使いやすくなっていく感じです。（この辺はCopilotを育成ゲームだと思うと楽しいです） このサイクルを回していくと、副次的な効果も出てきます。自分の Copilot 環境が育つだけじゃなくて、 チャット履歴を見返す習慣自体が「自分がどうコードを書いてるか」のメタ認知になる んですよね。「自分はこういう前提をよく省略するな」とか「このパターンの説明が苦手だな」みたいなことが見えてくる。AI ツールの設定を改善しているつもりが、実は自分のコミュニケーションの癖を棚卸ししている感じです。 チームへの展開もできます。後輩の Copilot の使い方をレビューするのにこのフローは結構使えて、エクスポートしてもらって横断分析すれば「ここ毎回手動でやってるから SKILL にしたら？」みたいな具体的なアドバイスができるんですよね。コードレビューはするのに、AI との対話のレビューはしてない、というチームは多いんじゃないかと。自分の tips を Markdown で共有して、チームの copilot-instructions.md に反映する流れを作ると、チーム全体の Copilot 活用レベルが底上げされていきます。 チャット履歴を分析するにあたって、JSON のままでは読めないので Markdown に変換するツールを前の記事「 Copilot Chat の会話履歴を Markdown で保存するパイプラインを作った話 」で紹介しています。横断分析をやってみたい方は、まずエクスポートして変換するところから始めてみてください。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Copilot チャット履歴から copilot-instructions.md と SKILL.md を育てる方法 first appeared on SIOS Tech Lab .

ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 その一つが、オンラインサポートチーム。オンライン会議や社内・社外イベントなど、配信関連のクオリティを向上させる目的で発足し、現在は10名ほどで活動しています。具体的な活動内容や、活動にかける思いについて、メンバーに聞きました。 自己紹介 Aさん 2019年4月に新卒入社。普段の業務内容はカスタマーサポート業務に関するアプリケーション及びシステムの開発・運用。オンラインサポートチームでの役割は、チームの運営実務・業務調整、社内における配信イベントの運営・機材サポート。趣味はゲーミングガジェット集め、eスポーツ観戦、写真撮影。 Sさん 2019年4月に新卒入社。普段の業務内容はデータセンターとオフィスのネットワーク設計・構築・運用。オンラインサポートチームでの役割は、社内・協賛イベントにおける配信イベントの運営・機材サポート・動画／写真撮影。趣味は廃道探索・環境測定。 Sさん 2021年4月 に新卒入社。普段の業務内容はコラボレーションツールおよび会計システムの運用・保守。オンラインサポートチームでの役割は、会議運営・音声編集・音声機材導入など。趣味は楽器演奏（ギター／ベース）と DTMでの楽曲制作。 オンライン会議やイベント配信の精度向上を目的に、専門チームが発足 みなさんは「オンラインサポートチーム（以下、オンサポ）」のメンバーということですが、所属部署や普段の業務はバラバラとお聞きしました。 Sさん そうですね。オンサポは会社公認の有志による活動で、さまざまな部署からメンバーが集まっています。ちなみに私は普段、社内プラットフォームチームに所属し、GWSやSlackといった外部ツールや、社内会計システムの運用などを担当しています。趣味はDTMを使った楽曲制作や、楽器の演奏です。 Aさん 私はカスタマーサポートグループ所属で、コールセンター業務にあたるスタッフさんが使うソフトウェアの開発や運用を行っています。趣味はゲームで、ゲーミングガジェット集めやeスポーツ観戦です。 Sさん 所属は Aさん と同じカスタマーサポートグループで、オフィスやコールセンターなどで使うネットワークのメンテナンスをしているエンジニアです。今は主に、オフィス周りのネットワークを設計しています。趣味は廃道の探索と環境測定です。 そもそもオンサポとはいつ頃から、どんな目的で発足したのでしょうか？ Sさん 正式なキックオフは2022年の4月ですが、チームが立ち上がる前から活動自体は始まっていたと記憶しています。当時はコロナ禍がまだ収束しきっていないタイミングで、在宅でのリモート会議や、全国の拠点をオンラインでつないで全社的な報告会を行う時、あるいは社内イベントの配信の際などに、画質や音質といった面でストレスを感じることが多かったんです。 そこで、当時のプラットフォームチームのリーダーの呼びかけによって、部署を超えて課題感を持つ有志が集まり、オンラインでの環境をサポートするチームが立ち上がったというのが大まかな経緯です。現時点でのメンバーは10人ほど。入れ替わりもありますが、ここにいる3人はわりと長いほうですね。 ちなみに、みなさんはどんな思いからオンサポへの参加を決めたのでしょうか？ Sさん 周囲からも「オンライン会議の品質を上げたい」という声は聞いていましたし、個人的にマイクなどの音響関係に興味を抱いていたこともあって、そうした部分で携われたらなと思い、参加することにしました。 Aさん そもそもチーム発足前から改善に向けて試行錯誤している人たちがいて、私はその様子を横から眺めていたのですが、正式にオンサポチームができるにあたって当時のリーダーがメンバーを募集したんです。みんなが頑張っている姿も見てきたし、個人的にも配信系に興味があったので、じゃあやってみようと。 Sさん 私はオンサポが立ち上がって少し軌道に乗ってきた頃に社内に向けた募集があって、参加を決めました。オンサポの活動自体は知っていましたし、趣味で少しカメラをやっていることもあって、業務として撮影機材を扱えるのは面白そうだなと。 趣味の範疇では触れない、本格的な機材を扱えるのが楽しい オンサポのミッションは「オンライン配信環境の品質改善」ということですが、具体的な活動内容や、これまでの成果を教えてください。 Sさん 今は隔週で1回1時間程度の定例会議を行なっています。社員からオンサポに寄せられた、配信環境にまつわる相談や問い合わせに対してみんなで議論をして、対応策を考えたり、プロジェクト化してメンバーをアサインしたり、進行中の案件の進捗を共有したりといった感じですね。 Sさん プロジェクトの具体的な内容としては、まず、「（品質を上げるための）機材の選定」です。映像関連はカメラ、音響関連はマイクやミキサーなど。実際に導入してみて、運用しながらどれくらい性能の向上や工数の削減につながったかを検証していきます。検証を踏まえて使い方を工夫したり、設定を変えたり、必要であれば別の機材を導入したりして、クオリティを上げていくのがメインの役割です。 Aさん 社内向けとなると、どこまでクオリティにこだわるかの線引きが難しいのですが、「音声が明瞭に聞こえる」というのは大前提として、映像もできるだけ鮮明にストレスなく届けられるようにしたいと考えています。 たとえば、社内オンラインイベントの配信中に映像や音響関連で気づいたことがあればSlackに書き込んで、イベント終了後にみんなで振り返りを行なっています。それで、次回はまた違う設定を試してみたり。社内だからこそ、ある程度の失敗は許容してもらえる前提で試行錯誤できるのは大きいですね。やっていくうちにノウハウを積み上げて、クオリティが上がってきた実感があります。 ちなみに、 Sさん は音響、 Sさん は撮影機材に関心があったということですが、オンサポチームでもご自身が興味のある分野を担当されているのでしょうか？ Sさん オペレーションに関しては全員が分かっている状態にすることが前提ですが、それに加えて各自が得意な領域、関心のある分野で役割を担っているイメージですね。僕の場合は音声機材だったりしますし、 Sさん はカメラをはじめとする映像周りの機材、 Aさん は調整周りを担当することが多いです。 Sさん 得意といっても僕の場合は趣味で一眼レフカメラを触っていた程度なのですが、オンサポでの活動を通じて学べたことも多く、いい経験をさせてもらっていると思います。先ほども言いましたが、趣味の範疇ではなかなか触れない機材を扱えるのも、すごく楽しくて。最近ではPTZカメラという、遠隔で方向や角度を調整したり、ズームしたりできる機材を導入しました。セミナーなどを配信する際、最後列から撮影しても観客の方を映さずに登壇者にズームできるので、とても便利ですね。 従業員の方からは、オンサポチーム発足後の配信のクオリティに対して、どんな声が寄せられていますか？ Aさん 評判はいいと思います。特に、日頃から外部のエンジニアが集まるオンラインイベントに参加している人からは「うちのオンサポはレベル高いね」と言ってもらえますね。 業務外活動の範疇で、できることを模索 もともとは社内の配信の品質を上げる目的で発足したオンサポですが、今は活動も幅も広がっているのでしょうか？ Sさん そうですね。たとえば、最近は動画制作の相談を受けるケースも出てきました。社内のとあるチームのイベント配信を我々が請け負った時に、後でアーカイブとして残す、あるいは外部に発信できるような形に編集することもあります。あとは、NIFTY Tech Dayというニフティが社外向けに行なっている技術カンファレンスがあるのですが、セッションの間に流す社員インタビューを僕らが撮影したこともありました。 ただ、配信とセットで撮影したり、動画を編集することはあっても、動画制作単体の依頼は受けていません。社内にはメディア関連の制作を請け負うチームも別にありますし、基本的にオンサポは配信のサポートがメインなので。どこまで枠を飛び越えるべきかの判断は、なかなか難しいですね。 メンバーとしては、活動の幅を広げていきたいのか、それとも役割を絞って、あくまで配信のクオリティを突き詰めていきたいのか、どちらですか？ Aさん そこは正直、悩みどころですね。配信のクオリティでいうと、ある意味でやり尽くした部分もあります。これ以上となると、さらに高い機材を導入するかみたいな話になりますが、果たして社内向けでそこまでやる必要があるのかと。また、コストカットや効率化についても突き詰めてきましたので、たとえば当初は何かのイベントを配信する時に準備と片付けを合わせて3時間かかっていたところを、今では合計1時間で終わらせられるようになっています。 Sさん かといって、活動の幅を広げようにもなかなか難しいですよね。たとえば、オンサポがクリエイティブチームみたいな形で、幅広く動画制作を請け負う方向性もあるとは思います。ただ、そうなるともう“仕事”の範疇になってしまう。オンサポは本業外の社内活動という位置付けなので、あまり手を広げすぎるのもどうなんだろうと。 結局のところ、我々の軸足はあくまでエンジニアなので、今は本業に支障のない範囲で次に何ができるのかを模索しているところです。 ただ、オンサポの活動自体はこれからも続けていきたいと考えていらっしゃいますか？ Sさん そうですね。活動自体は楽しいので、僕自身は可能な限り続けたいと思っています。もちろん、年次を重ねてさらに多忙になればそうも言っていられなくなるかもしれませんが、仮に僕らが抜けたとしても“ユーザー”が困らないよう、配信にまつわる困りごとをカバーするような体制や仕組みは作っておきたいですね。 後編に続きます！ 今回はニフティのオンラインサポートチームのインタビューの様子をお届けしました。続きは近日公開の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報