電話対応をAIにお任せ。24時間365日対応のコールセンターを安価に立ち上げる方法

こんにちは！デジタル・マーケティング部の山内です。
「また、現場のエースが電話対応で手を止めている……」
「夜間や休日のトラブル対応、本当はもっと手厚くしたいけれど、人手も予算も足りない」
「大切なお客様からの着信を、これまで何件取りこぼしてきたのだろうか」
製造業の経営層、そしてDX推進を担う皆様。2026年3月という今、貴社のフロントオフィスでは、このような「現場の疲弊」が常態化していませんか？
労働人口の減少がより深刻化した現在、製品の品質が良いのは当たり前。今、顧客が求めているのは「必要な時に、すぐに繋がる」という安心感です。しかし、限られた人的リソースの中で、24時間365日のサポート体制を築くことは、これまでの常識では「莫大なコスト」を意味していました。
「顧客満足度を上げたい。しかし、コストも人も限界だ」
この、一見すると解決不能に思える矛盾を打破する切り札が、Amazon Connect（アマゾン コネクト）と最新の生成AIを組み合わせた、次世代の「AI問い合わせ受付システム」です。本記事では、大規模な設備投資を一切行わずに、安価かつ迅速に24時間365日の問い合わせた受付体制を構築する方法を詳しく解説します。

1. 2026年、製造業が直面する「電話対応」の構造的限界

2026年現在、製造業界においても「熟練工の引退」が進む一方で、新しい人材の確保は極めて困難です。この状況下で、旧来の電話対応体制を維持することは、以下のような深刻なリスクを伴います。

① 熟練スキルの「ブラックボックス化」

中規模製造業の強みは、製品に対する深い知識ときめ細やかな対応にあります。しかし、「〇〇のことなら工場長のAさんに聞けばいい」という運用は、Aさんの不在時にお客様を待たせるだけでなく、Aさん自身の生産性を著しく低下させます。電話対応が特定の「個人」の知識に依存していることは、組織の継続性において最大の脆弱性です。

② 24時間対応への「物理的・コスト的壁」

取引のグローバル化や短納期化が進む中、夜間や休日の問い合わせ対応はもはや必須条件となりつつあります。しかし、外部のコールセンターへ委託すれば莫大な月額固定費が発生し、自社で夜間シフトを組めば、社員の離職リスクを招きます。

③ 「声の資産」の未活用

日々、電話で交わされる顧客の要望やクレームは、次期製品開発のヒントが詰まった「宝の山」です。しかし、アナログな電話対応では、それらは担当者のメモや記憶の中に消えてしまい、組織のデータとして蓄積・活用されることはありません。

2026年、製造業が直面する「電話対応」の構造的限界の図

2. Amazon Connectが解決する「設備とコスト」の問題

これらの課題を解決するための最強のインフラが、AWS（Amazon Web Services）が提供するクラウド型コンタクトセンター（問い合わせ受付）サービス「Amazon Connect」です。

物理的な「設備」という概念を捨てる

従来の問い合わせ受付体制の構築には、オフィスにサーバー（PBX）を設置し、専用の電話回線を何本も引き、多額の保守費用を支払うのが常識でした。
しかし、Amazon Connectはクラウドサービスです。物理的なハードウェア投資は一切不要。PCとインターネット環境さえあれば、最短数日で本格的な窓口を立ち上げることができます。

「完全従量課金」が実現する低コスト運用

中規模製造業にとって、月額固定費の増大は避けたいはずです。Amazon Connectは、実際に電話を利用した分だけ料金が発生する「従量課金制」を採用しています。

• 問い合わせが少ない時期は、コストを最小限に。
• 展示会後や新製品発売時など、着信が増える時期だけリソースを拡張。
  この経営上の柔軟性は、オンプレミス型のシステムや定額制の委託サービスでは決して得られないメリットです。

3. 生成AIとの融合：「実利主義」の電話自動化

Amazon Connectの真価は、最新の生成AIを連携させることで、電話対応が「自動応答」から「知的な対話」へと進化する点にあります。ここで重要になるのが、ビジネスの現場で確実に成果を出すための「実利主義AI」の考え方です。

① AIによる「自然な」音声対話

「〇〇の方は1番を……」という、顧客を苛立たせる案内はもう必要ありません。AIが顧客の自然な発話を理解します。
「先週納品された機械が動かない。エラーコード102が出ている」
という発話に対し、AIは即座に内容を認識し、適切な初期対応を案内します。

② RAG（検索拡張生成）による回答精度の向上

AIが誤った回答をする（ハルシネーション）ことを防ぐために、RAG（Retrieval-Augmented Generation）技術を活用します。
これは、AIに自社の「製品マニュアル」や「技術FAQ」を直接参照させる仕組みです。AIは勝手な推測をせず、貴社が保有する正しい情報のみを根拠に回答します。これにより、24時間365日、ベテラン社員に代わってAIが正確な技術回答を行うことが可能になります。

③ 感情分析とスマートな「人間への引き継ぎ」

AIは声のトーンから、顧客の緊急度や感情を察知します。激しいクレームや複雑な相談と判断した場合は、それまでの会話の「要約テキスト」と共に、即座に担当者のスマートフォンへ転送します。担当者は内容を把握した状態で受話器を取れるため、スムーズな解決へと導けます。

【仕組みの解説】Amazon Connect × 生成AI（RAG）の連携図

【Amazon Connectの弊社事例はこちら】

4. 人件費削減と顧客満足度（CS）向上の相乗効果

自動問い合わせ受付の導入は、単なるコストカットではありません。それは、人間とAIの「最適配置」による経営戦略です。

単純作業からの解放

「カタログの送付依頼」や「納期確認」「よくある故障の対処法」といった定型的な問い合わせをAIに任せることで、社員は「電話に振り回される毎日」から解放されます。人間は、設計や品質改善、重要顧客への提案活動といった、より付加価値の高い業務に集中できるようになります。

「いつでも繋がる」という究極のCS

顧客にとって最大の不満は「電話が繋がらないこと」です。AIであれば、同時に100件の着信があっても、すべて即座に応答可能です。深夜3時の緊急トラブルでも、AIが1次受付を行い、解決策を提示したり修理受付を完了させたりすることで、「この会社なら安心だ」という強い信頼を醸成します。

5. 知見の活用：B2Bコミュニケーションと信頼性の担保

最新技術を現場で機能させるには、単なるシステム導入以上の「設計の工夫」が求められます。
例えば、B2Bコミュニケーションにおける対話設計のノウハウがあれば、顧客が迷うことなくAIと対話し、問題を解決できる導線を作ることが可能です。また、絶対に止まることが許されないミッションクリティカルなシステム（金融・証券レベル）を支えてきた厳格な品質管理基準を、このAI問い合わせ受付システムの構築にも適用することが、製造業の基幹業務を支える上での大前提となります。
さらに、AIの導入を「ツールを入れること」自体を目的にせず、人件費削減や売上向上といった「具体的な成果」に直結させる視点が必要です。

6. 失敗しないための「スモールスタート」ロードマップ

大規模な刷新にはリスクが伴います。まずは限定的な範囲から始め、効果を検証しながら拡大する「段階的導入」が賢明です。

ステップ1：夜間・休日の「AI受付」

まずは営業時間外の電話対応から始めます。AIが顧客の用件を聞き取り、内容を要約して翌朝担当者にメールやチャットで飛ばす。これだけで、夜間の呼び出しがなくなり、休み明けの「折り返し電話ラッシュ」の負担が激減します。

ステップ2：特定の製品・FAQの自動回答

問い合わせの多い特定の製品について、マニュアルやFAQに基づいたAI回答を開始します。これにより、現場の社員への技術問い合わせ電話を30%〜50%削減することを目指します。

ステップ3：基幹システムとの統合

最終的には、在庫管理システムやCRM（顧客管理システム）と連携させ、AIが電話口で在庫状況を答えたり、注文を直接システムに入力したりする「真の自動化」を実現します。

失敗しないための「スモールスタート」ロールマップ

7. セキュリティとデータ資産の保護

製造業において、技術情報の漏洩は死活問題です。
クラウド化に不安を感じる方も多いですが、最新のクラウド環境は世界最高水準のセキュリティ基準をクリアしています。また、生成AIを利用する際も「入力したデータがAIの学習に利用されない設定」を徹底することで、貴社の機密情報を安全に守りながら利便性だけを享受することが可能です。
データを活用し、電話での会話を「テキストデータ」として蓄積すれば、それは製品改善や市場動向分析のための貴重な経営資源へと変わります。

8. まとめ：電話対応を「コスト」から「戦略」へ

2026年、製造業における電話対応の自動化は、もはや「あれば便利なもの」ではなく、生き残るための「必須装備」です。Amazon Connectと生成AIを活用すれば、かつては何千万円もかかった高度な問い合わせ受付体制を、驚くほどの低価格とスピードで手にすることができます。
未来の製造現場は、工場の中だけではありません。お客様と繋がるその一報の電話から、新しい製造業の形が始まります。

株式会社シー・エス・エスについて

1976年創業の株式会社シー・エス・エスは、半世紀にわたり証券・金融システムの最上流工程を支えてきた独立系SIerです。この「絶対的信頼性」を基盤に、現在はシステム開発やAWS導入支援に注力しています。Amazon Connectにおいては、既存の50名規模の開発・保守チームが在宅勤務へ移行する際、Lambda等を活用した受付環境をわずか2〜3日で構築。社用携帯コストを約68%削減し、管理者の取り次ぎ負担を解消した「実例」に基づくノウハウを保有しています。基盤構築からアプリ開発まで一気通貫で、実利的なDXに伴走します。

【詳細はこちら】

www.css-net.co.jp

最後に：具体的な導入イメージをお持ちいただくために

「自社の電話業務なら、どの程度のコストで、どこまで自動化できるか？」
「今あるマニュアルをAIに読み込ませて、どこまで回答が正確になるのか？」
具体的なシミュレーションや、弊社の検証事例に基づいたデモのご相談は、ぜひお気軽にお問い合わせください。貴社の現場に最適な、地に足のついたDXプランをご提案いたします。

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

小学生の時から「あたしンち」が大好きです！（笑）最近ふと思いたって再びYoutubeで見始めたら止まらなくて…。無心で見ちゃうんです（笑）両親はなかなか癖ありですが、なんだかんだであの家族ほんとに仲いいですよね♪

＼クラウド構築なら、株式会社シー・エス・エスへ／

古いWindowsサーバーを使い続ける本当のリスクとは？中規模製造業向け・低予算で実現するクラウド移行術

こんにちは！デジタル・マーケティング部の山内です。
中規模製造業において、ITインフラを支える情報システム部門、あるいは兼任でIT管理を担われているご担当者の皆様、日々の業務本当にお疲れ様です。
工場の生産管理システム、独自の在庫管理データベース、設計用のCADデータを保管するファイルサーバーなど、御社の屋台骨を支えているシステムの中に「Windows Server 2012」や「Windows Server 2012 R2」といった、すでにメーカーの延長サポートが終了した古いOSは眠っていませんか？
「工場内のクローズドな環境だから大丈夫だろう」「現状で問題なく動いているし、何より移行のための莫大な予算が下りない」と、ハードルの高さから対応を先送りにしてしまうお気持ちは、痛いほどよく分かります。
しかし、ITベンダーによくある「サポート切れは危険なので、すぐに数千万円かけて最新の機器に全面刷新しましょう」といった、いたずらに不安を煽るご提案を真に受ける必要はありません。本記事では、現場のリアルなリスクを冷静に整理した上で、「莫大な初期予算をかけず」に、クラウド（AWS）と専用ツールを活用して、賢く低予算で移行する具体的なアプローチについて解説します。

1. なぜ、製造業の現場には「古いWindowsサーバー」が残りやすいのか

IT業界の人間からすると「OSのアップデートやサーバーの入れ替えは定期的に行うのが当然」と思われがちですが、製造業の現場において、古いサーバーが長年放置されやすいのには特有の切実な理由があります。

第一に、「安定稼働のジレンマ」です。工場の生産ライン（FA機器）や独自の業務プロセスに深く結びついたシステムは、一度安定して稼働し始めると「システムを止めること」自体が大きなリスクになります。OSを最新版にバージョンアップしたことで、連携している古い生産機器のソフトウェアが動かなくなる、あるいは独自のカスタマイズを加えたExcelマクロがエラーを吐くといった懸念から、あえて「触らぬ神に祟りなし」という選択をしがちです。

第二に、「予算獲得の壁」です。製造業において、新しい工作機械の導入や工場の拡張など「直接利益を生み出す設備投資（プロフィットセンターへの投資）」には予算がつきやすい傾向があります。一方で、目に見える売上アップに直結しにくい「社内サーバーのOS入れ替え（コストセンターへの投資）」に対して、経営層から数百万〜数千万円規模の稟議を通すのは非常に困難です。「動いているものをなぜわざわざ高いお金を出して変える必要があるのか」という経営陣の問いに対し、明確な費用対効果を示すことは容易ではありません。

第三に、「閉域網（クローズドネットワーク）への過信」です。「インターネットに直接繋がっていない工場内の独立したネットワークだから、外部からハッキングされる心配はない」という考え方です。しかし、現代の高度化したセキュリティ環境において、この過信は致命的な罠になり得ます。

なぜ、製造業の現場には「古いWindowsサーバー」が残りやすいのかの挿入図

2. サポート切れOSを使い続ける「3つの現実的なリスク」

では、実際にサポートが終了したWindowsサーバーを使い続けると、どのような現実的なリスクが待ち受けているのでしょうか。決して脅すわけではありませんが、客観的な事実として以下の3点に留意する必要があります。

リスク1：サプライチェーンを狙う「ランサムウェア」の標的

近年、サイバー攻撃のトレンドは大きく変化しています。大企業を直接狙うのではなく、セキュリティ対策が手薄になりがちな「中規模の部品メーカーや協力会社」の脆弱なサーバーを足がかりにして、サプライチェーン全体を機能不全に陥れる手法が急増しています。
サポートが切れたWindowsサーバーは、新たに発見された脆弱性に対するセキュリティパッチ（修正プログラム）が提供されません。保守業者の持ち込み端末や、データのやり取りに使うUSBメモリなどを経由して、たとえ閉域網であってもランサムウェア（身代金要求型ウイルス）に感染し、工場の生産ラインが長期間停止してしまう事例が後を絶ちません。一度感染すれば、データの復旧費用だけでなく、稼働停止による莫大な機会損失が発生します。

リスク2：親会社や大手取引先からの「セキュリティ監査」と取引要件

大手自動車メーカーや電子機器メーカーなどのトップ企業は現在、自社のサプライチェーンを構成する全企業に対して、厳格なサイバーセキュリティガイドラインの遵守を求めています。
定期的に送られてくるセキュリティ監査のチェックシートにおいて、「サポート切れのOSを稼働させているサーバーが存在する」という事実は、重大なコンプライアンス違反とみなされるケースが増えています。ごまかして回答したことが後日発覚した場合のペナルティは計り知れず、最悪の場合、システムの移行が完了するまで「新規発注の停止」や「取引口座の凍結」といった致命的な経営ダメージに直結する恐れがあります。

リスク3：ハードウェアの老朽化による「突然死」と部品枯渇

OSが古いということは、それを動かしている物理サーバー（ハードウェア）自体も、導入から5年〜10年以上が経過しているケースが大半です。サーバー内部のコンデンサや冷却ファン、ハードディスクの駆動部は消耗品であり、ある日突然ショートしてデータが完全に消失する「突然死」のリスクを抱えています。
いざ壊れてから慌ててメーカーに修理を依頼しても、「すでに保守部品の提供期間が終了しているため直せません」と宣告されるケースが多発しています。中古市場で同じ型番の部品を探し回るような綱渡りの運用は、企業のインフラを預かる状態として非常に危険です。

サポート切れOSを使い続ける「3つの現実的なリスク」

3. ベテランの退職に伴う「完全なブラックボックス化」の危機

さらに、古いシステムを維持し続けることで直面する、目に見えない最大の脅威があります。それは、システムの老朽化以上に深刻な「人材の退職に伴う、完全なブラックボックス化」です。
長年稼働しているシステムは、「なぜその設定になっているのか」「どこでどんな処理が行われているのか」といった仕様書が最新化されていないことがほとんどです。当時のシステム導入を主導し、複雑な業務フローとサーバーの仕様を唯一紐づけて理解していた「ベテランの社内SE」や「システムに詳しい現場の担当者」が、定年退職などで現場を去ってしまうと、残されたメンバーにはシステムが完全にブラックボックス化してしまいます。
「あの人が辞めてしまった今、サーバーがエラーを吐いても誰も直し方が分からない」「再起動の順番すらマニュアルがない」という属人化の限界は、明日起きてもおかしくない現実のトラブルとして多くの製造業で顕在化しています。システムの中身が分からなくなる前に、最新の管理しやすい環境へ移行しておくことは、企業防衛の観点から急務と言えます。

4. 「高額なオンプレミス全面刷新」は不要。クラウドという選択肢

これらの課題に対して、これまで主流だった解決策は「新しい物理サーバーを数百万円で購入し、システム会社のエンジニアに高額な費用を払って数ヶ月かけて移行する」というオンプレミス（自社保有）環境での全面刷新でした。
しかし、予算とIT人材が限られる中規模製造業にとって、このハードルは高すぎます。そこでおすすめしたいのが、Amazon Web Services（AWS）をはじめとするパブリッククラウドへの移行です。
クラウド最大のメリットは「初期費用（ハードウェア購入費）が不要」であり、利用した分だけ毎月支払う「従量課金制」である点です。ピーク時の負荷に合わせてオーバースペックな高額サーバーを買う必要がなくなり、必要な時に必要なだけの性能を低予算で利用できます。多額の設備投資（Capex）から、月々の運用経費（Opex）へと切り替えることで、経営層への予算申請（稟議）のハードルも劇的に下がります。また、物理的なサーバー管理から解放されるため、情シス担当者の保守負担も大幅に軽減されます。

5. 「AWS Migration Hub」を活用した、コストを抑える賢い移行ステップ

「クラウドが良いのは分かったが、自社の複雑な古いシステムが本当に移行できるか分からない。事前の調査（アセスメント）だけでもITコンサルタントに数百万円請求されるのでは？」というご不安もあるでしょう。
ここで活躍するのが、AWSが提供している移行支援サービス「AWS Migration Hub」です。このツールを活用することで、移行前の調査から計画、実行までを低予算かつ低リスクで進めることが可能になります。具体的な3つのステップをご紹介します。

ステップ1：現状の正確な可視化と「不要なサーバーの断捨離」

長年運用されたシステム環境は、「誰が何のために使っているか分からない謎のサーバー」が乱立しがちです。AWS Migration Hubの機能（Discovery Connectorなど）を使うと、現状のネットワーク内にあるサーバーの構成や、どのサーバー同士が通信し合っているのか（依存関係）を自動的に収集・可視化できます。
「誰も使っていないのに稼働し続けているテストサーバー」や「統合可能なファイルサーバー」を見つけ出すことで、そのままクラウドに持っていく無駄を省き、移行対象をスリム化して大幅なコスト削減を実現します。

ステップ2：適正サイズの算出（Right-sizing）でランニングコストを最適化

古い物理サーバーは、導入時に「念のため」と余裕を持たせて高スペックなものを買っていることが多く、実際にはCPUの数％しか使っていないことがよくあります。AWS Migration Hubは、収集した稼働状況のデータをもとに「クラウドに移行した場合、どの程度のサーバースペック（インスタンスサイズ）が最適で、月額コストはいくらになるか」を精緻に算出してくれます。これにより、移行後の予算オーバーを防ぎ、経営陣へ具体的な費用対効果（ROI）を明確に提示できます。

ステップ3：移行進捗の一元管理でプロジェクトの頓挫を防ぐ

実際にAWSへ移行する際、複数のサーバーを段階的に移行していくことになります。AWS Migration Hubは、各サーバーの移行ステータスを一つのダッシュボードで一元管理できるため、「今どのシステムの移行が終わっていて、何が残っているのか」が一目でわかります。専任の高度なITプロジェクトマネージャーがいなくても、社内で状況を把握しながら着実に進行させることができ、移行作業の手戻りや漏れを防ぎます。
このように、サーバーの移行は決して「一か八かの高額な大手術」ではありません。AWS Migration Hubのようなツールを活用し、まずは「可視化と計画」だけを低予算で実施（スモールスタート）することで、サポート切れの脅威から安全かつ確実に脱却する道が開けます。

6. 株式会社シー・エス・エスについて

株式会社シー・エス・エスは1976年の創業以来、極めて厳格な要件が求められる金融・証券の基幹システムを支えてきました。そこで培った「絶対にシステムを止めない」堅牢なプロジェクト管理力は、工場稼働を支える製造業のシステム移行においても強力な基盤となります。現在はAWSへのクラウドシフトやデータ分析、自社SaaS「Qube」の展開、生成AIの実利的な活用も推進中です。長年の実績と最新技術を掛け合わせ、製造業の皆様へ安全かつ低予算なシステム移行を確実にご支援いたします。

7. まとめ：まずは「現状の可視化」から始めませんか？

古いWindowsサーバーを抱えたまま、属人化とサポート切れという漠然とした不安の中で日々の業務を回し続ける必要はありません。莫大な予算や高度なIT人材がいなくても、AWSのようなクラウド技術と便利なツールを活用して、自社のペースで安全な環境へ移行する手段は確実に存在します。
まずは「今の自社のサーバー環境がどうなっているのか」、現状を正しく把握することから第一歩を踏み出してみませんか？私たちは、システム移行に対して高いハードルを感じているお客様の状況に寄り添い、経営陣も納得する無理のない移行計画をご一緒に考えます。システムのサポート切れやクラウド移行に関するちょっとした疑問やご相談でも構いませんので、どうぞお気軽にお問い合わせください。

【合わせて読みたい】

blog.css-net.co.jp

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

先日、母校のゼミの教授に会いに行ったところ、1代上・4代上・6代上・7代上の先輩方もいらっしゃり、みんなで楽しく談笑しました！
代は違っても、どことなく皆さんのタイプが似ていてとても興味深かったですし、そのゼミに入ったことが誇らしく思えました（笑）

＼クラウド構築なら、株式会社シー・エス・エスへ／

「社内情報の検索」に時間がかかっていませんか？自社専用のAI検索システムを作る

こんにちは！デジタル・マーケティング部の山内です。
製造業の現場やオフィスにおいて、「あの資料はどこにあるのか？」「過去の類似製品の仕様書が見つからない」といった経験は誰にでもあるのではないでしょうか。デジタルトランスフォーメーション（DX）が叫ばれる昨今においても、多くの企業で「社内情報の検索」に莫大な時間が割かれています。
本記事では、中規模製造業の皆様に向けて、Amazon KendraとAmazon Bedrockを活用した「自社専用のAI検索システム（RAG）」の構築による、抜本的なナレッジ管理と業務効率化のアプローチについて解説します。

製造業が抱える「情報のサイロ化」と検索の課題

事業規模が拡大し、製品ラインナップや取引先が増加するにつれて、企業内のデータは爆発的に増加します。特に中規模製造業においては、成長の過程で様々なシステムが部門ごとに導入されることが多く、情報がサイロ化（孤立化）しやすい傾向にあります。

• 散在するデータ保管場所: ファイルサーバー、SharePoint、社内ポータル、図面管理システム、個人のローカルフォルダなど、データが様々な場所に分散している。
• 多様なフォーマット:  WordやExcelの仕様書、PDFのISO関連文書、過去の不具合報告書、ベテラン技術者が残したメモ書きなど、形式が統一されていない。
• 属人化による検索の限界: 「あの件は〇〇部門の△△さんしか場所を知らない」といった属人化が発生し、担当者の不在や退職によって重要なナレッジが引き出せなくなる。

ある調査によれば、ビジネスパーソンは就業時間の約20%を「情報の検索」に費やしていると言われています。製造業において、過去の設計データや品質保証（QA）のトラブルシューティング記録を即座に引き出せないことは、製品開発の遅延や、過去と同じミスの繰り返し（歩留まりの悪化）に直結する深刻な経営課題です。

課題の可視化の図

一般的な生成AI（ChatGPTなど）をそのまま使えない理由

近年、生成AIによる業務効率化が注目されていますが、製造業の社内情報の検索において、一般的なAIサービスをそのまま導入するには以下のようないくつかの高い壁があります。

1. 社内情報を知らない（学習データの限界）:一般的な生成AIは、インターネット上の公開データを元に学習しています。そのため、「自社の製品Aにおける過去の不具合対応履歴を教えて」と質問しても、当然ながら正しい答えは返ってきません。
2. ハルシネーション（もっともらしい嘘）のリスクと精度の壁: 近年、AIの性能向上によりハルシネーションは激減傾向にあります。しかし、AIが学習していない「自社特有の製品仕様」や「過去の数値データ」を無理に答えさせようとした場合、推測で不正確な情報を生成してしまうリスクは依然として残ります。厳密な仕様や過去の数値を扱う製造業において、1%でも不正確な情報を元に判断を下すことは致命的な事故に繋がるため、「絶対に事実に基づいた回答をさせる仕組み」が不可欠です。
3. セキュリティと機密保持の懸念: 設計図面、特許情報、顧客要件などの機密データを外部のAIシステムに直接入力することは、情報漏洩のリスクを伴うため、多くの企業で禁止されています。

ブレイクスルーとなる「RAG（検索拡張生成）」技術とは

これらの課題を解決し、生成AIの恩恵を安全かつ正確に享受するための技術がRAG（Retrieval-Augmented Generation：検索拡張生成）です。
RAGとは、ユーザーが質問した内容に対して、まず「社内のデータベースやファイルサーバー」から関連する文書を「検索（Retrieval）」し、その検索された社内文書を根拠として、AIが回答を「生成（Generation）」する仕組みです。
これにより、AIは推測で答えるのではなく、「貴社のファイルサーバーにある〇〇年〇月の不具合報告書（リンク）によれば、原因は部品Xの熱膨張であり、対策として素材Yに変更したと記載されています」といった具合に、確実な社内情報を元にした正確な回答と、その情報源（参照元文書）の提示を行うことが可能になります。

【RAGの検証結果はこちらのブログにて】

blog.css-net.co.jp

Amazon Kendra と Amazon Bedrock による最適解

この高度なRAGシステムを、エンタープライズレベルのセキュリティと精度で実現するために最適なプラットフォームが、AWS（Amazon Web Services）が提供する「Amazon Kendra」と「Amazon Bedrock」の組み合わせです。

1. 高度なエンタープライズ検索エンジン「Amazon Kendra」

Amazon Kendraは、機械学習を活用したインテリジェントな検索サービスです。従来のキーワード一致だけの検索とは異なり、質問の「意味」を理解してファイルを探し出します。また、SharePointやS3、社内データベースなど、複数の異なる保管場所にあるデータを横断的にインデックス化できるため、「どこに保存されているか」を人間が意識する必要がなくなります。

2. 安全な生成AIプラットフォーム「Amazon Bedrock」

Amazon Bedrockは、多様な高性能な基盤モデル（Claudeなど）を、インフラ管理不要で利用できるフルマネージドサービスです。最大の特徴は「セキュリティ」です。AWS PrivateLinkなどを活用することで、貴社のAWS環境という閉じたネットワーク内で安全に処理を完結させることも可能です。機密性の高い製造ノウハウや設計データを扱う上で、この強固なセキュリティは必須条件と言えます。

解決策の仕組みの図

自社専用AI検索システムがもたらす3つの価値

このシステムを導入することで、貴社の業務には以下のような変革がもたらされます。

1. 検索時間の劇的な削減: 何時間もかけて複数のフォルダを掘り起こしていた作業が、チャットに質問を投げかけるだけで数秒で完了します。浮いた時間は、より付加価値の高い設計・開発業務に投資できます。
2. ナレッジ管理の高度化と技術伝承: 定年退職を迎えるベテラン技術者の暗黙知や、過去の膨大なプロジェクトの経験則を、AIを通じて若手社員がいつでも簡単に引き出せるようになります。これは最強の教育ツールでもあります。
3. 意思決定の迅速化: 営業部門が顧客からの技術的な問い合わせを受けた際にも、AI検索を使って過去の類似事例や製品仕様を即座に確認できるため、顧客へのレスポンス速度が飛躍的に向上します。

株式会社シー・エス・エスの強み

株式会社シー・エス・エスは、1976年の創業以来、約半世紀にわたりミッションクリティカルな金融基幹システムを支え続けた実績と絶対的な信用力を持っています。当社は自社SaaS「Qube」の開発・運営も手がけ、常に先進技術を探求しています。AI活用においては徹底した実利主義を貫いており、シー・エス・エスのInnovation LABで検証済みのRAG（検索拡張生成）技術を、業務効率化ソリューションとして提案いたします。金融品質の確かな要件定義力で、貴社のシステム構築に伴走します。

まとめと次のステップ

社内に眠る膨大なデータを「探す労力」から解放し、「活用する資産」へと変えることは、激動の市場を勝ち抜く中規模製造業にとって不可欠なDXの第一歩です。Amazon KendraとAmazon Bedrockを活用したセキュアな自社専用AI検索システムは、貴社のナレッジ管理を全く新しい次元へと引き上げます。
「自社のファイル環境でも導入できるのか？」「まずは一部門のデータだけでPoC（概念実証）を行いたい」など、どのような疑問でも構いません。業務効率化とシステム導入の専門家である株式会社シー・エス・エスへ、ぜひお気軽にご相談ください。

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

今年ついに堂々と花粉症といえるようになってしまいました（泣）くしゃみは止まらないし、目もかゆいし…とはいえ、外には出たいし洗濯物も外に干したい！ので、近々耳鼻科で花粉症の薬をもらってきます。

＼クラウド構築なら、株式会社シー・エス・エスへ／

IT担当者が辞めても大丈夫。「人の手」を介さずにシステムを運用する自動化の技術

こんにちは！デジタル・マーケティング部の山内です。
中規模製造業を支える経営層の皆様にとって、今最も頭の痛い問題は「IT人材の不足」ではないでしょうか。特に、自社のシステムを長年支えてきたベテラン担当者の退職や、特定の個人にしか分からない「業務の属人化（ブラックボックス化）」は、事業継続における巨大なリスクです。
「新しい人を採用すれば解決する」——そうお考えかもしれませんが、激化するIT人材争奪戦の中で、自社の仕組みを熟知した優秀な人材を確保し続けるのは至難の業です。
そこで、株式会社シー・エス・エスが提案するのは、人を採用するのではなく、「クラウドの機能で業務を代替する」という実利的な解決策です。

「人」に頼る運用から「仕組み」が動く運用へ：NoOpsの衝撃

IT現場では、OSのアップデート、セキュリティパッチの適用、サーバーの稼働監視など、定型的でありながら「失敗が許されない」作業が日々発生します。これらを「人の手」で行っている限り、ミスは避けられず、担当者が不在になれば途端に立ち行かなくなります。

この課題を解決する核心的な技術が、AWS Systems Managerを活用した「運用自動化（NoOps）」です。

• 自動パッチ適用: 脆弱性が見つかっても、深夜に担当者が作業する必要はありません。あらかじめ設定したルールに基づき、システムが自動で最新の状態を維持します。
• 構成管理の自動化: 数百台のサーバー設定を、一箇所のコントロールパネルから一括で制御。誰が作業しても同じ品質が保たれます。
• 修復の自動化: システムの異常を検知した瞬間、事前に定義されたスクリプトが走り、担当者が気づく前に復旧を試みます。

これは単なる「省力化」ではありません。「IT担当者が辞めたらシステムが止まる」という不安から、経営を解放するための戦略的投資です。

「人」に頼る運用から「仕組み」が動く運用へ：NoOpsの衝撃

なぜ、シー・エス・エスが選ばれるのか

世の中にクラウドベンダーは数多く存在しますが、私たちシー・エス・エスグループには、他社にはない「信頼の裏付け」があります。

1. 半世紀にわたる「絶対に失敗できない」領域での実績

私たちは1976年の創業以来、約50年にわたり、日本の金融・証券インフラという、一秒の停止も許されないミッションクリティカルなシステムを支え続けてきました。大手証券会社や主要な金融機関の元請けとして培った品質管理能力と、要件定義からPM領域までを担う上流工程の知見は、中規模製造業の基幹システム運用においても強力な安心感を提供します。

2. 「実利主義」に基づく最新技術の実装力

私たちは生成AIやクラウドを単なる流行とは考えていません。「いかに業務効率を上げるか」「いかに成果に直結させるか」という実利にこだわっています。
例えば、最新の生成AIツールを最適に組み合わせた社内ナレッジの活用や、自社SaaS「Qube」の開発・運営を通じて、常に「自らが実験台となり検証済みのソリューション」を蓄積しています。
「技術のための技術」ではなく、お客様のビジネスを止めないための「実利的なDX」を提案できるのが、シー・エス・エスの強みです。

シー・エス・エスの強みの図

「守り」のITから、経営を加速させるITへ

IT担当者が定型業務に追われている時間は、本来、生産工程の改善やデータ活用といった「攻め」の施策に充てられるべき貴重なリソースです。
AWS Systems Managerによる自動化を導入することで、属人化を排除し、労働集約型のモデルから脱却しましょう。私たちは、証券システム開発で磨かれた高い設計能力をもって、貴社の既存システムを「人が介在しなくても回る」強靭な構造へと作り変えます。
また、私たちは現在、自社製品「Qube」の提供など、ストック型ビジネスへの転換を進めています。これは、私たち自身が「労働集約型からの脱却」を体現し、そのノウハウをお客様へ還元していくという決意の表れでもあります。
「担当者が辞める前に、打てる手がある」
貴社のIT資産を、特定個人のスキルに依存しない「企業の資産」へと進化させませんか。まずは、今ある小さなお悩みからお聞かせください。

【AWS導入・構築支援の事例はこちら】

www.css-net.co.jp

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

先日久しぶりに「逃げ恥」を見ました！大人になってからは初めて見たのですが、みくりさんやひらまささんの聡明さを改めて知ったとともに、今だからこそ共感できるところもあって、とても面白かったです！

＼クラウド構築なら、株式会社シー・エス・エスへ／

災害発生時、翌日には業務再開できますか？低コストで実現する「会社のデータの守り方」

こんにちは！デジタル・マーケティング部の山内です。

「もし今日、大規模な地震が発生したら？」「もし明日、基幹システムがランサムウェアに感染したら？」
中規模製造業を営む経営層・IT部門の皆様にとって、これらは単なる「万が一」の想定ではなく、今すぐ解決すべき経営課題です。サプライチェーンの中核を担う中規模製造業において、システムの停止は自社の損失に留まらず、取引先への供給停止、ひいては社会的信用の失墜に直結します。
しかし、「強固なBCP（事業継続計画）には莫大なコストがかかる」と諦めてはいませんか？
実は、AWS（Amazon Web Services）の最新技術を活用することで、「金融機関レベルの堅牢性」と「圧倒的な低コスト」を両立したデータ保護が可能になります。
本記事では、半世紀にわたり日本の金融インフラを支えてきた株式会社シー・エス・エスの視点から、明日から実践できる「負けないためのデータ戦略」を解説します。

1. 製造業を襲う2つの脅威：自然災害とランサムウェア

現在、製造業の拠点を脅かしているのは地震などの自然災害だけではありません。近年、サプライチェーンの脆弱性を狙った「ランサムウェア攻撃」による工場停止事例が急増しています。

・自然災害のリスク： 物理サーバーが損壊すれば、データの復旧には数週間から数ヶ月を要します。
・サイバー攻撃のリスク： バックアップデータそのものが暗号化されてしまえば、身代金を支払わない限り、業務再開は絶望的です。

これらに対し、「翌日には最低限の業務を再開できる」状態を作るには、従来のオンプレミス（自社所有）型バックアップでは限界があります。

製造業を襲う2つの脅威

2. AWS BackupとS3 Glacierが変える「守り」の常識

私たちが推奨するのは、AWSのマネージドサービスを組み合わせた「クラウド・ハイブリッド型バックアップ」です。

■ AWS Backupによる自動化と一元管理
AWS Backupは、クラウド上のデータだけでなく、オンプレミス環境のデータも一括して保護できるフルマネージドサービスです。「いつ」「どのデータを」バックアップするかをポリシー設定するだけで、ヒューマンエラーを排除した確実な運用が実現します。

■ Amazon S3 Glacierによる驚異の低コスト化
「数年前のデータも念のため残しておきたいが、ストレージ費用が嵩む」という課題を解決するのがAmazon S3 Glacierです。これは「アーカイブ専用」のストレージクラスで、データの取り出しに時間はかかりますが、保存コストを極限まで抑えることができます。

• 「実利主義」の選択
  頻繁に使うデータは標準ストレージへ、万が一の際の備え（長期保管）はGlacierへ。この使い分けにより、従来のサーバー維持費と比較して大幅なコストダウンが可能になります。

3. なぜ「シー・エス・エス」が選ばれるのか：金融品質の技術力

クラウド移行を支援する企業は数多くありますが、なぜ私たちシー・エス・エスが、中規模製造業の皆様のBCP対策において独自の価値を提供できるのか。それには明確な理由があります。

① 50年間、一度の失敗も許されない「金融・証券システム」を完遂

シー・エス・エスは1976年の創業以来、国内大手証券会社や大手シンクタンクの基幹システムを「元請け（プライム）」として支えてきました。
金融業界のシステムは、1秒の停止も許されないミッションクリティカルな世界です。そこで培われた「金融レベルの堅牢性を担保する設計力」と「厳格なプロジェクト管理（PM）能力」を、そのまま製造業のBCP策定に注入します。

② 「実利主義」に基づく自社SaaSの運用実績

私たちは、技術を単なる知識としてではなく、自らのビジネスを支える武器として活用する「実利主義」を貫いています。
その象徴が、自社開発SaaSである「Qube」です。このサービスはAWS上で稼働しており、日々膨大なデータを安定的に処理・運用しています。自社でクラウドのメリットも運用の難所も知り尽くしているからこそ、机上の空論ではない、お客様の現場で「本当に動く」最適なクラウド活用を提案できるのです。

③ 上流工程から一貫してサポートする「課題解決力」

BCP対策で最も重要なのは、ツールを導入すること自体ではなく、「いかにして業務を止めないか」「どう復旧させるか」という要件定義と設計です。
シー・エス・エスおよびリライフ・ジャパンは、証券システムの開発において最上流工程からプロジェクトに参画し、複雑な業務フローを整理・構築してきた実績があります。この「完遂する力」こそが、不測の事態においても確実に業務を再開させるための最大の安心材料となります。

サプライチェーン全体のクラウドBCP連携の図

まとめ：データは「過去の記録」ではなく「未来の資産」

BCP対策は、単なるコストではありません。災害や攻撃を受けても「うちは翌日に復旧できる」という事実は、取引先に対する最強の営業力になります。
シー・エス・エスは、金融レベルの堅牢な技術力をベースに、AWSを活用した低コストなBCP対策から、自社SaaS「Qube」の運営で培った実践的なノウハウまで、お客様のフェーズに合わせた最適なソリューションを提案します。
「現在のバックアップ体制で、本当に明日復旧できるのか？」
少しでも不安を感じられたら、まずは当社の技術ブログをご覧いただくか、お気軽にお問い合わせください。

【関連ブログ】

blog.css-net.co.jp

blog.css-net.co.jp

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

3年ほど前から趣味でnoteを書いています。ここでの決まりは「AIを一切使わないこと」。これはnoteに限らずですが、自分の感情や想いを書くときは、多少へんであれ、自分の言葉で書きたいタイプです（笑）

＼クラウド構築なら、株式会社シー・エス・エスへ／

初めてのAWS移行。「とりあえずクラウド化（リフト）」の後に待つ落とし穴と回避策

こんにちは！デジタル・マーケティング部の山内です。

製造業の経営者様、あるいは情報システム部門を統括される皆様。

工場の生産管理システムや、全社の基幹システムの「クラウド移行」を検討される中で、このような言葉を耳にすることはないでしょうか？

「サーバーの保守期限（EOS）が迫っているから、とりあえずAWSに移しておこう」

「まずはクラウド化して、それからDXを進めよう」

これは、多くの企業様が最初に直面する選択肢であり、決して間違いではありません。しかし、この「とりあえず」という判断の裏側には、移行プロジェクトが完了した後に初めて顕在化し、経営を圧迫しかねない「巨大な落とし穴」が潜んでいます。

本記事では、年商50億～2,000億円規模の製造業のお客様に向けて、クラウド移行における「リフト＆シフト」の真実と、創業50年を迎える私たち株式会社シー・エス・エスが提案する、移行後の運用まで見据えた「失敗しない移行戦略」について解説します。

1. そもそも「リフト」と「シフト」とは？ ～老舗旅館の引越しに学ぶ～

専門的なIT用語を使わずに、「老舗旅館の引越し」に例えてご説明しましょう。

長年使い込んだ、趣はあるが設備の古い木造旅館（オンプレミス）から、最新鋭の高層ビル（クラウド）へ移転するプロジェクトを想像してください。

移行には、大きく分けて2つのアプローチがあります。

・リフト（Lift）
「とりあえず引越し」です。木造旅館で使っていた重厚な座卓、大きな屏風、紙の宿帳などを、そのまま高層ビルのフロアに運び込みます。
配置も変えません。ビルの最新設備（カードキーや自動空調）があっても、使い方が分からないので、相変わらず手書きの宿帳を使い、重い鍵をお客様に渡します。場所は最新ビルになりましたが、中身は「昔のまま」です。
・シフト（Shift）
「リニューアルオープン」です。高層ビルの間取りや設備に合わせて、運営スタイルを根本から見直します。
重い座卓は運び込まず、ビルの内装に合った機能的な家具を新調します。手書きの宿帳はやめて、タブレットでのチェックインを導入します。ビルの最新設備をフル活用し、少人数でも快適なサービスを提供できるように「作り変える」のです。
多くの企業様は、「まずはリフト（引越し）を済ませて、落ち着いてからシフト（模様替え）しよう」と考えます。
「とりあえず荷物を運んでしまえば、後はどうにかなるだろう」と。
しかし、クラウドの世界において、この「後はどうにかなる」は通用しません。むしろ、「とりあえずリフト」を選択した瞬間から、じわじわと真綿で首を絞められるような問題が発生し始めるのです。

「リフト」と「シフト」の違いの図

2. 「とりあえずリフト」の後に待つ3つの落とし穴

「リフト」だけを行って安心してしまうと、運用開始から数ヶ月後に「こんなはずではなかった」という悲鳴が上がることになります。具体的にどのような事態が待ち受けているのか、3つの落とし穴を見ていきましょう。

① コストの落とし穴：請求書を見て青ざめる「従量課金」の罠

最も多いトラブルがコストです。「クラウドにすればハードウェア管理費がなくなるから安くなる」と思っていませんか？
クラウドは電気代と同じ「従量課金制」です。使った分だけ請求されます。
オンプレミスのサーバーは、製造業で言えば「自社発電所」のようなもので、一度建ててしまえば、どれだけ電気を使っても追加料金はかかりません。そのため、従来のシステムは「ピーク時（月末処理など）に合わせて最大パワーで動かす」ように設計されています。
これをそのままクラウドに「リフト」するとどうなるか。
誰も使っていない深夜や休日であっても、最大出力の巨大なサーバーが高額な料金メーターを回し続けることになります。クラウドならではの「使わないときは自動で電源を切る（オートスケーリング）」という機能を使えるように改修していないためです。
結果として、「期待したほどコストが下がらない」どころか、「以前の維持費の1.5倍、2倍の請求が来た」という事態に陥ります。これは決して珍しい話ではありません。

② 運用の落とし穴：「クラウド＝全自動」という危険な誤解

「クラウドに移せば、運用は全部Amazon（AWS）がやってくれるんでしょう？」
これもよくある誤解です。
クラウド事業者が保証してくれるのは、あくまで「場所」と「インフラ（電源やネットワーク）」の安全までです。その上で動くOS（Windowsなど）や、皆様の業務アプリケーションの面倒までは見てくれません。これを「責任共有モデル」と呼びます。
「リフト」しただけのシステムは、中身が古いままです。
OSのセキュリティパッチ当て、バックアップの確認、ウイルス対策ソフトの更新……これら情シス部門を悩ませてきた「泥臭い作業」は、クラウドに行ってもそのまま残ります。
むしろ、クラウドという慣れない環境になった分、設定ミスによる情報漏洩リスクなどは高まります。「楽になる」と思って移行したのに、情シス担当者は「慣れないクラウドの管理」と「減らない運用作業」の板挟みになり、以前より疲弊してしまうのです。

③ DX停滞の落とし穴：データはクラウドにあるが、誰も使えない

最大の落とし穴は、ビジネスの成長機会を失うことです。
「クラウド化したから、これで工場のデータをAI分析できるぞ」と意気込んでも、「リフト」しただけでは何もできません。
なぜなら、データが「古いタンス」に入ったまま運ばれてきただけだからです。
各工場の生産データはバラバラの形式で保存され、連携されていない。データベースの構造も古く、最新のAIツールでは読み込めない。
結局、担当者がクラウド上のサーバーからCSVデータをダウンロードし、Excelで手作業で加工してメールで送る……という「昭和のアナログ業務」が残ります。
これでは、DX（デジタルトランスフォーメーション）の入り口に立っただけで、中に入れない状態です。多額の費用をかけて引越しをしたのに、得られたのは「場所が変わった」という事実だけ。これでは、経営判断として成功とは言えません。

3. 株式会社シー・エス・エスのコンサルティングは何が違うのか？

では、どうすればこの落とし穴を回避できるのでしょうか。
私たち株式会社シー・エス・エスは、単に「AWSへの移行作業」を代行するだけのベンダーではありません。
私たちは1976年の創業以来、約半世紀にわたり、「絶対に止まってはいけない」金融・証券業界の基幹システムを支え続けてきました。国内有数の大手証券会社様や大手金融グループ様のプライム（元請け）パートナーとして、システム開発の最上流工程から深く関わってきた実績があります。
クラウド移行において最も重要なのは、技術選定ではなく「何のために移行するのか」という目的の定義です。
株式会社シー・エス・エスは、証券システム開発で培った強力な要件定義力に定評があります。「現行通り」に移すのではなく、「あるべき姿」を描き出し、最初からデータ活用やコスト最適化を見据えた「シフト（最適化）」へのロードマップを策定します。
技術ありきではなく、お客様のビジネスゴールから逆算できる点が、私たちの最大の強みです。

4. 自社SaaS「Qube」開発で培う、実践的な技術力

私たちが提案する「クラウド活用」や「AI導入」は、机上の空論ではありません。
シー・エス・エスでは、BtoBコミュニケーションプラットフォーム「Qube（キューブ）」を自社で開発・運営しています。
Qubeはクラウドネイティブな環境で構築されており、現在も最新の生成AIを活用した機能の実装などを進めています。
自社製品として実際にクラウドサービスを運用し、日々機能改善を行っているからこそ、「運用フェーズで何が起きるか」「どこでコストが膨らむか」を熟知しています。教科書的な知識ではなく、自社の痛みと成功体験に基づいた「生きたノウハウ」を、お客様のシステムに還元します。

シー・エス・エスの強みの図

5. まとめ：50年の信頼を、貴社の新たな武器に

「とりあえずクラウドへ」という号令で動き出したものの、具体的な道筋が見えず不安を感じているプロジェクトはありませんか？
株式会社シー・エス・エスは、まもなく創業50年を迎える歴史あるIT企業でありながら、クラウドやAI活用を経営トップ主導で推進する「変革企業」でもあります。
金融業界で長年培ってきた「約束を守る力（プロジェクト完遂力）」と、自社プロダクト開発で磨き続ける「最新技術の実践力」。この両輪で、貴社のクラウド移行を単なる「サーバーの引越し」で終わらせず、次の成長を生み出す「投資」へと変えるお手伝いをいたします。
まずは、現状のシステム課題や、将来実現したい姿についてお聞かせください。上流工程に精通した私たちのコンサルタントが、貴社の言葉で対話させていただきます。

クラウド移行、AI活用による業務改革、基幹システム刷新に関するご相談は、お気軽にシー・エス・エスまでお問い合わせください。

【お問い合わせはこちらから】

www.css-net.co.jp

【関連資料】

www.css-net.co.jp

www.css-net.co.jp

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

マイブームは、本の音読です（笑）

＼クラウド構築なら、株式会社シー・エス・エスへ／

サーバー保守期限は「進化」の合図：AWS移行成功のチェック項目

こんにちは！デジタル・マーケティング部の山内です。

「サーバーの保守期限がいよいよ迫ってきたけれど、何から手をつければいいのかわからない」「クラウド移行、特によく聞くAWSへの移行って本当に安全なの？」と、不安や焦りを感じているシステム担当者の方は多いのではないでしょうか。

経済産業省が警鐘を鳴らした「2025年の崖」問題。2026年を迎えた今、多くの企業にとってレガシーシステムの刷新は「検討事項」ではなく、デジタル競争を勝ち抜くための「生存戦略」へとフェーズが変わっています。物理サーバーの老朽化対応は、単なる機器の買い替えではなく、企業のデジタルトランスフォーメーション（DX）を加速させる絶好のチャンスです。

今回は、長年日本の金融・証券インフラを支えてきたシー・エス・エスグループの視点から、自社運用（オンプレミス）からAmazon Web Services（AWS）へ移行する際に絶対に外せないチェックリストを詳しく解説します。ぜひ、最後までチェックしてみてくださいね。

なぜ今、オンプレミスからAWSへの移行が選ばれているのか

国内のIT市場では、従来のオンプレミス環境から、AWSなどのパブリッククラウド環境への移行需要が引き続き高い水準にあります。

クラウド移行には、物理的なサーバー管理からの解放、柔軟な拡張性、そして災害対策（DR）の強化など、多くのメリットがあります。しかし、いざ移行となると「既存のシステムがそのまま動くのか」「セキュリティは大丈夫か」といった懸念はつきものですよね。

特に、失敗が許されないミッションクリティカルなシステムを運用されている場合、その慎重さはなおさらではないでしょうか。私たちシー・エス・エスグループは、1976年の創業以来、約半世紀にわたり「失敗が許されない」金融業界でシステムを構築し続けてきました。その経験から言えるのは、クラウド移行の成否は、事前の現状分析と計画準備で8割が決まるということです。

AWS移行を成功させるための必須チェック項目

移行をスムーズに進めるために、検討段階で確認しておくべきポイントを3つのステップにまとめました。

1. 現状把握と「移行パス」の決定

まずは、現在のシステム資産を正しく把握しましょう。

棚卸しと優先順位： すべてのサーバーを一度に移行するのはリスクが高いため、影響の少ない周辺システムから段階的に行うのが定石です。

移行手法（6つのR）の選択： AWSが提唱する「6つのR」から、最適な戦略を選びます。代表的なものは以下の3つです。

　・リホスト（リフト）： OSやアプリケーションをそのままクラウドへ移す。スピード重視。

　・リプラットフォーム： 基本的な構成は変えず、DBなどをクラウド最適化されたマネージドサービスに置き換える。

　・リファクタリング（シフト）： クラウドネイティブな構成に作り変え、最大限の恩恵を享受する。

保守期限が迫っている場合に最初の候補になりやすいのは、まずはスピード重視の「リホスト」でクラウドへ移し、その後に段階的に最適化（シフト）していく戦略です。

「3つの主要な移行パス（3つのR）の概念図」

2. セキュリティとガバナンスの設計

「クラウドはセキュリティが不安」という声も聞かれますが、実は適切な設定を行えばオンプレミス以上の強固な環境を構築できます。

　・責任共有モデルの理解： 「クラウド自体のセキュリティ（AWS側の責任）」と「クラウド内のセキュリティ（ユーザー側の設定責任）」の境界線を明確にします。

　・金融レベルの基準： 金融機関では、FISC（金融情報システムセンター）の安全対策基準への準拠など、厳格な対応が求められます。シー・エス・エスグループでは、閉域環境での運用や機密性の高いドキュメント管理など、金融系ベンダーとしての知見を活かした設計を提案しています。

3. コストと運用体制の見直し

クラウドは「使った分だけ支払う」従量課金制です。

　・コスト試算： 単純な月額費用の比較だけでなく、データセンターの維持費や運用人件費を含めた総保有コスト（TCO）で比較します。また、AWSリセール（再販）サービスを活用することで、直接契約よりもコストを最適化できる場合があります。

　・運用自動化（MSP）： 移行後は、マネージドサービスの活用や運用の自動化により、管理者の負担を劇的に軽減することが可能です。

「コストの全体像を可視化する「TCO（総保有コスト）」比較図」

▽クラウド移行でシステム管理コストを大幅に削減した当社の事例はこちら▽

パートナー選びで決まる「移行の質」

クラウド移行は、単に「場所を移す」作業ではありません。ビジネスの成長に合わせてシステムをどう進化させるかという、中長期的な視点が不可欠です。

現在、IT市場は「スピード重視のクラウド専業型」と「堅牢なガバナンスに強みを持つ変革型SIer」の二極構造になっています。私たちシー・エス・エスグループのような変革型SIerは、大規模システムのガバナンス維持、上流工程（要件定義）からの深い関与、そして長年の運用で培ったドメイン知識（業務知識）に強みがあります。

現在、当社は「AWSパートナー」としての活動を強力に推進しており、金融システム開発のノウハウと、最新のクラウドネイティブな技術を融合させた体制を整えています。

私たちが提供する価値は、単なる技術提供ではありません。「お客様のビジネス要件を正確に理解し、最適なシステム要件へと翻訳する能力」です。これにより、要件定義の漏れや手戻りを最小限に抑え、高品質かつコスト最適化された移行を実現します。

保守期限は「進化」の合図です

サーバーの保守期限が迫っている今こそ、これまでのシステムを見直し、より柔軟で強固な基盤へと生まれ変わるチャンスです。私たちは、50年の歴史で築いた信頼と最新の技術を組み合わせ、お客様のDXを全力でサポートします。

「どこから手をつければいいかわからない」「自社の業務に合わせた最適な構成を提案してほしい」といったお悩みをお持ちの方は、ぜひお気軽にシー・エス・エスグループにご相談ください。

お客様の大切なシステムを、次の50年も安心して運用できる形へ。私たちと一緒に作り上げていきましょう！

【関連ブログ】

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

最近、高校の友人たちとスパ活（スパイスについて語ったり、本格インドカレー屋さん巡りをすること）を始めました！オールスパイスが特に好きです(^^)/

＼クラウド構築なら、株式会社シー・エス・エスへ／

AWS re:Invent 2025「Frontier Agents」衝撃の余波 ～「運用監視」が消える日、金融システム運用はどう変わるか～

こんにちは！デジタル・マーケティング部の山内です。
2025年、ラスベガスで開催された「AWS re:Invent」。世界中の技術者が固唾を飲んで見守る中、発表されたのは単なる新機能ではありませんでした。それは、私たちが長年慣れ親しんできた「システム運用」という概念そのものを過去のものにするかもしれない、衝撃的なイノベーション——「Frontier Agents（フロンティア・エージェント）」の登場です。
「運用監視の仕事が、なくなるかもしれない」。
この言葉を聞いて、背筋が凍る思いをしたインフラエンジニアや運用管理者は少なくないでしょう。しかし、これは遠い未来のSFの話ではありません。AWSが発表した「AWS DevOps Agent」や「AWS Security Agent」は、人間の常時介入なしに、数時間から数日間にわたり自律的にタスクを遂行する能力を持っています。
本記事では、この「Frontier Agents」が金融システム運用にもたらす不可逆的な変化と、その激動の中で企業が取るべき生存戦略について、創業50年にわたり金融ITを支えてきたシー・エス・エスグループの視点から紐解きます。

Frontier Agentsとは何か：自動化から「自律化」へ

これまで私たちが取り組んできた「自動化（Automation）」は、あらかじめ決められた手順書（Runbook）をスクリプトに置き換えることでした。しかし、今回の「Frontier Agents」は次元が異なります。それは「自律化（Autonomy）」です。
AWS re:Invent 2025で発表された主要なエージェント群、特に「AWS DevOps Agent」は、障害のアラートを検知すると、自らログを調査し、根本原因を推論し、修正案を提示し、承認されれば復旧作業まで完結させます。また、「AWS Security Agent」は設計段階から脆弱性を継続的に監視し、デプロイメントの承認までを判断します。
これまでの「AIアシスタント（Copilot）」が、人間が指示を出すのを待つ「副操縦士」だったとすれば、Frontier Agentsは、目的を与えれば自ら考え行動する「自律的な労働力」です。これは、24時間365日の有人監視体制を敷き、膨大なコストと人手不足に悩まされてきた金融機関にとって、まさに福音とも言える技術革新です。

「NoOps」の甘い罠と、金融システムに残るリスク

では、明日からすべての運用監視担当者を解雇し、すべてをAIエージェントに任せればよいのでしょうか？
答えは「No」です。特に、ミッションクリティカルな金融システムにおいては、安易な「NoOps（運用レス）」への飛びつきは致命的なリスクを招きます。
競合となるクラウド専業ベンダー（クラウドネイティブ・イノベーター）は、「スピード」と「新技術」を武器に、こうした最新機能を即座に実装することを提案するでしょう。彼らの技術力とスピード感は素晴らしいものですが、金融機関の現場には、技術だけでは解決できない「ドメイン（業務）の壁」が存在します。
「なぜそのアラートが出たのか」という技術的な原因はAIが特定できても、「その障害が業務（決済、約定、対外接続）にどのようなインパクトを与え、どの部署にどのような順序で連絡し、金融庁へどう報告すべきか」という判断は、業務文脈（コンテキスト）を理解していなければ不可能です。AIにすべてを委ねた結果、システムが「ブラックボックス化」し、いざという時に人間が誰も状況を把握できていない——これは金融システムにとって許容できないリスクです。

シー・エス・エスグループの解：Pragmatic Cloud for Enterprise

ここで重要になるのが、私たちシー・エス・エスグループが掲げる「Pragmatic Cloud（実利的なクラウド）」というアプローチです。
私たちには、創業以来50年にわたり、日本の金融インフラを支え続けてきた実績があります。メインフレーム時代から培った「絶対に止めてはならないシステム」の運用ノウハウと、金融業務特有の商習慣や規制（FISC安全対策基準など）への深い理解。これこそが、AI時代における私たちの最大の武器です。
大手SIerのような重厚長大で高コストな運用体制でもなく、クラウド専業ベンダーのような「技術一辺倒」でもない、シー・エス・エスグループは、「AIエージェントを『監督（Supervise）』する運用」という新しいスタイルを提案します。

1. AIと人間の役割分担の再定義
   定型的な監視や一次対応は「DevOps Agent」に任せ、人間はAIが提示した推論結果の妥当性を判断し、業務影響を評価する「監督者」へとシフトします。私たちは、長年の経験に基づき、「どこまでをAIに任せ、どこから人間が介入すべきか」という安全な境界線を設計します。
2. 「信頼（Trust）」と「革新（Innovation）」のハイブリッド
   シー・エス・エスグループは、社内の「Innovation LAB」において、生成AIやローカルLLMの実証実験を繰り返しています。最新のAWS技術をキャッチアップしながらも、それを金融機関が安心して導入できる形に「翻訳」して実装する。この「老舗の安心感」と「ベンチャー並みの技術的俊敏性」の融合こそが、他社にはない私たちの強みです。

「運用監視」は消えるが、運用者は「進化」する

「運用監視」という単純作業は、確かに消えるでしょう。しかし、それは悲観すべきことではありません。人間は、ログの行を目で追うような作業から解放され、より高度な「システムの信頼性向上」や「ビジネス価値の創出」に注力できるようになるからです。
AWS re:Invent 2025で示された未来は、恐怖ではなく、チャンスです。
しかし、そのチャンスを掴むためには、新技術を盲信するのではなく、自社の業務に合わせて飼いならす知恵が必要です。

「クラウド構築を検討しているが、AI運用への移行に不安がある」
「既存ベンダーの運用コストが高止まりしているが、品質は落とせない」

そのような悩みをお持ちのCIO、システム責任者様は、ぜひシー・エス・エスグループにご相談ください。
私たちは、50年の歴史で培った「信用」を基盤に、最新の「Frontier Agents」を使いこなす、貴社の最も現実的で頼れるパートナーになることをお約束します。
ご一読いただきまして、ありがとうございました。

▽サービスについて相談したい！そんな方はこちらから▽

www.css-net.co.jp

この記事を書いた人

名前：山内 恵美

経歴：転職でシー・エス・エスに入社の2年目。SE6年、マーケティングは1年目。

趣味：カフェに行くこと、ドラマを見ること、散歩

最近、高校の友人たちとスパ活（スパイスについて語ったり、本格インドカレー屋さん巡りをすること）を始めました！笑 オールスパイスが特に好きです(^^)/

＼クラウド構築なら、株式会社シー・エス・エスへ／

【AWS】ECS on Fargate 検証してみた！

こんにちは、TC部所属のN.Nです。

AWSのコンテナサービスであるECSについて、「基本的な仕組み」と「最低限の構築手順」を試しました。検証してみてわかったことをまとめましたので、参考になれば幸いです。

ECSはコンテナを簡単に実行・管理できるサービスです。

これは、コンテナ実行環境の管理負担を、軽減したい場合に有効です。（ECSでは、コンテナの配置やスケーリング、ヘルスチェックなどが自動化されるため、コンテナ実行環境のインフラ運用にかかる、負担軽減が期待できます。）

この記事はこんな方におすすめです。

• コンテナってそもそもなに？
• AWSは触ったことがあるが、ECSは初めて
• ECSの基本的な仕組みを把握したい

概要

AWSのコンテナサービスは、一般的なコンテナの概念を基盤としています。まず、一般的なコンテナの概要から説明します。

一般的なコンテナの概要

コンテナとは？

アプリケーションの実行に必要な依存物（OS、ミドルウェア、アプリケーション）をパッケージ化したものです。

パッケージ化することで、「必要なパッケージが入っていない」あるいは「ランタイムとライブラリに整合性が取れていない」などの複数環境で起こりうる"差分"を無くすことができます。

オーケストレーターとは？

コンテナ①、コンテナ②、、、のように複数のコンテナを効率的に管理・運用するための機能がオーケストレーターです。スケーリング設定や自動デプロイ機能もあり、本番環境で重宝する機能です。

コントロールプレーンとデータプレーンとは？

コンテナ技術を活用するには、コントロールプレーンとデータプレーンという2つの概念を理解することが必要です。これに加えて、リポジトリの理解も欠かせません。

コントロールプレーン

コンテナの管理・制御を行います。コンテナの配置、スケーリング設定など、コンテナのライフサイクル全体を管理します。代表例はGoogleが開発した「Kubernetes」です。

データプレーン

実際にコンテナが動作し、ワークロード（アプリケーション）を実行する「実行環境」です。データプレーン上でネットワーク通信やストレージのやり取りなど、実際のデータの処理が行われます。代表例は、Docker社が提供する「Docker」です。

リポジトリ

OS、ミドルウェア、アプリケーションが一つになったコンテナのイメージを保管するためのものです。代表例はDocker社が提供する「Docker Hub」とGitHubが提供する「GitHub Container Registry」です。

AWSのコンテナの概要

AWSでは、コンテナを管理するコントロールプレーンにECSやEKS、コンテナが稼働するデータプレーンにEC2やFargate、そしてコンテナイメージを保管するリポジトリにECRというサービスがあります。

今回はECS on Fargeteの構成で構築するため、ECS、Fargateを紹介します。

コントロールプレーン側：ECSとは？

Amazon Elastic Container Service (以下、ECS) は、AWSが提供するフルマネージドなオーケストレーターです。ECSは以下の要素から構成されます。

• タスク
  • 実行中のコンテナのこと
• タスク定義
  • タスクの個数や使用するイメージのCPUやメモリを定義する
• サービス
  • タスクを管理する機能
  • 指定したタスク数を維持しようとしてくれる
• クラスター
  • ECSのサービスやタスクを実行するためのグループのこと

AWS Black Belt Online Seminar 『Amazon ECS 入門』 P.14

データプレーン側：Fargateとは？

AWS Fargete（以下、Fargete）は、ECSやEKSでコンテナを実行するためのサーバレスなデータプレーンです。

サーバやOSの管理が不要でインフラの運用不可を大幅に軽減できます。

AWSコンテナサービスのアーキテクチャ

コンテナのアーキテクチャは、コントロールプレーンとデータプレーンの組み合わせで構成されます。コストや拡張性、信頼性などから最適な組み合わせを選ぶ必要があります。

例）ECS on EC2、ECS on Fargete     etc...

構築してみよう

構成図

今回、構築する構成は以下となります。

※通常ECSはセキュリティの観点からプライベートサブネットに配置されますが、今回は検証のためパブリックサブネットに配置します。

流れ

今回はWebサーバを動かすコンテナを、ECSで起動させるために構築してみましょう。

構築手順は以下となります。

1. ネットワーク周りの構築
2. ECSの構築
3. アクセスの確認

※今回のメインはECSです。ネットワーク周りの構築手順は要約して記載します。

※必要なIAMロールなどは、作成されている前提とします。

※こちらの参考サイトに従い、構築しました。

　社内知識を活用した生成 AI チャットボットを構築したい

１．ネットワーク周りの構築

以下のリソースを作成してください。

※設定は基本、デフォルト値です。

• VPC　×１
• Subnet　
  • AZ-a用　×１
  • AZ-c用　×１
• RouteTable　×１
• InternetGateway　×１
• SecurityGroup　
  • ALB用　×１
  • ECS用　×１
• ALB　×１
• TargetGroup　×１

VPC、Subnet、RouteTable、InternetGatewayを作成

SecurityGroup ALB用を作成

SecurityGroup ECS用を作成

ALBを作成

TargetGroupを作成　※ターゲットは登録しない

２．ECSの構築

タスク定義を作成

主な設定

• 起動タイプ
  • AWS Fargate、EC2、マネージドインスタンスから選択可能
  • AWS Fargeteを選択
• OS
  • Linux/X86_64、Linux/ARM64、Windows Server 2022 Full/X86_64などから選択可能
  • Linux/X86_64を選択（デフォルト値）
•  ネットワークモード
  • awsvpc、bridge、ホスト、なしから選択可能
  • awsvpcを選択（デフォルト値）
• タスクロール
  • ecsTaskExecutionRoleを選択（事前に作成しておく）
  • 作成方法はこちら↓

    Amazon ECS タスク実行IAM ロール - Amazon Elastic Container Service

• イメージURI（Uniform Resource Identifier）
  
  • ECRパブリックギャラリーで公開されているイメージURIを貼り付け
  • URIの取得はこちら↓

　　　　　https://gallery.ecr.aws/nginx/nginx

• • （今回は検証のためAWSが公開しているイメージURIを使用しました。自作のイメージURIを使用することももちろん可能です。）

イメージURIの設定

タスク定義の作成

タスク定義を作成できました。

プライベートレジストリについて（赤枠参照）

実際の案件では、認証情報の保護の観点からプライベートレジストリは「オン」にしておきましょう。

詳細はこちら↓

Amazon ECS での AWS 以外のコンテナイメージの使用 - Amazon Elastic Container Service

クラスターの作成

主な設定

• クラスター名
• インフラストラクチャ
  • AWS Fargete（サーバーレス）を選択

クラスターの作成

サービスの作成

主な設定

• タスク定義のリビジョン
  • １を入力
  • タスク定義の内容（設定）を変更するたびに自動で採番されるバージョン番号であり、タスクの実行時にどの設定を使うかを指定するために利用される
• 必要なタスク
  • 検証なので１を入力
  • 常に稼働状態を維持してほしいタスク数を入力します
• VPC、Subnet、SecurityGroup
  
  • 先ほど作成したリソースを選択
• ロードバランシング
  • 先ほど作成したALBを選択後、既存のリスナーとターゲットグループを選択

追加設定

• サービスの自動スケーリング
  • アプリケーションの負荷に応じて稼働中のタスク数を自動で増減させる機能です。自動スケーリングを希望するのであれば、有効にしてください。
  • 現時点では無効にする

サービスの設定　「サービス名」

サービスの設定　「環境」

サービスの設定　「デプロイ」

サービスの設定　「ネットワーキング」

サービスの設定　「ロードバランシング」

サービスの設定　「リスナーとターゲットグループ」

サービスの設定　「オプション：スケーリング」

サービスの作成　完了

３．アクセスの確認

ECS周りも作成できたので、ALB経由でコンテナにアクセスできるのか確認しましょう。

ALBのURLをコピーします。（赤枠参照）

ブラウザで検索します。

Nginxのデフォルトページが表示されました！

これで、Nginxが正しくコンテナ内で起動し、外部からのアクセスを受け付けていることが確認できました。

運用設計について

ECS on Fargateを運用する上で設計すべき項目は、ログ、メトリクス、イメージ、セキュリティ、負荷分散、障害対策、スケーリングなど多岐にわたります。

実際に案件で設定する際は、公式の以下のサイトをご確認ください。

Amazon ECS のモニタリング - Amazon Elastic Container Service

Amazon ECS トラブルシューティング - Amazon Elastic Container Service

Amazon ECS でコンテナをスケジュールする - Amazon Elastic Container Service

Amazon Elastic Container Service のセキュリティ - Amazon Elastic Container Service

まとめ

今回のブログでは記載しませんでしたが、タスクの自動復旧やスケール設定も検証してみました。実際の案件では、このようなマネージド機能を上手に活用していく必要があると思いました。

今回は、必要最小限の構築でしたが、次回は、タスクのログ管理やモニタリングをさらに深掘りし、実運用に耐えうる構成を考えてみたいです。

【関連記事】

blog.css-net.co.jp

参考サイト

社内知識を活用した生成 AI チャットボットを構築したい

Amazon ECS タスク実行IAM ロール - Amazon Elastic Container Service

https://gallery.ecr.aws/nginx/nginx

Amazon ECS での AWS 以外のコンテナイメージの使用 - Amazon Elastic Container Service

スタートアップのためのコンテナ入門 – 導入編 | AWS Startup ブログ

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_Amazon_ECS_Introduction_0831_v1.pdf

この記事を書いた人

ニックネーム：NN
経歴：入社3年目です。主にAWSのインフラ案件に携わってきました。最近はBIツールにも触れています。
一言：港町や海沿いの風景が好きです。写真は、横浜の海を撮影したものです。神戸や熱海、舞浜のあたりも好きです。

＼株式会社シー・エス・エスは、新しい仲間を募集中♪／
資格取得も支援しています！詳しい職種紹介・募集要項はリクルートサイトへ

【Amazon AppStream 2.0 実践ガイド】最小ステップでアプリケーション配信環境を構築！

こんにちは、TC部所属のN.Nです。
今回は Amazon AppStream 2.0 について、実際の案件で構築してみてわかった「基本的な仕組み」と「最低限必要な構築ステップ」をまとめます。

AppStreamは、アプリケーションのみを配信できるサービスです。
利用者にWindowsのデスクトップやOS設定を触らせたくない場合に特に有効で、アプリケーションのみ配信したい場合に活躍します。

この記事はこんな方におすすめです。

• AWSは使っているが、AppStreamは初めて
• AppStreamの全体像をざっくり把握したい
• 最小限の構築ステップを知りたい

AppStream 2.0とは

概要

AppStream 2.0 は、AWSが提供するアプリケーションストリーミングサービスです。
クライアント環境にアプリをインストールせず、ブラウザから利用できます。

特徴

アプリケーションのみを配信することにより、OSやWindowsの機能を利用者に触らせない構成が可能です。（設定でDesktopを配信させることも可能です）

基本構成の理解

AppStreamは以下の要素で構成されます。

1. イメージ（Image）
   　アプリと設定をまとめた仮想マシンのテンプレート。これを元に配信されます。
2. イメージビルダー（Image Builder）
   　イメージを生成するための作業環境。
3. フリート（Fleet）
   　ユーザーにアプリを提供するサーバー。スケーリング設定もここで行います。
4. スタック（Stack）
   　ユーザーにどのアプリをどの設定で配信するかを定義します。
5. ユーザープール（User Pool）
   　利用するユーザーを登録します。

[AWS Black Belt Online Seminar] Amazon AppStream 2.0 P.36より

この5つを理解しておくと、構築手順がスムーズになります。

構築してみよう

構築環境

今回、AppStreamを構築するAWS環境は以下となります。

簡易的な構成図

AppStreamの最小構築手順

AWSコンソールにあるAppStreamサービスから構築します。

手順は以下の公式サイトに則り、実施します。

Image Builder を起動し、ストリーミングアプリケーションをインストールして設定する - Amazon AppStream 2.0

※あくまでAppStreamの構築手順のため、VPCなどのネットワーク周りや必要なIAMロールは、事前に作成しているものとします。

１．イメージビルダーを起動
AWSコンソールからOSやインスタンスタイプを選択し、起動します。

主な設定

• OS
• インスタンスタイプ
• ネットワーク
  • イメージビルダーからインターネットに出れるような構成にする（アプリのインストール時、インターネットと通信するため）
• セキュリティグループ
  • 最低限、443ポート（または80ポート）は開放

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　etc...

追加設定

• IAMロール
  • AppStreamからAWSサービスを操作したい場合は設定
  • AppStream用のポリシー（AmazonAppStreamFullAccess）などが付与されているロールを選択
• Active Directory
  • イメージビルダーを組織のActive Directoryに参加させたい場合は設定

構築中（20分程待機）

構築完了

２．アプリケーションをインストール
イメージビルダー内で必要なソフトウェアや設定を行います。

※ソフトウェアのインストール方法や基本設定は通常のWindows上の設定方法と同じです。

基本設定

• 日本語化
• タイムゾーン　etc...

利用したいアプリのインストール

• 例）VSCode　

　※インストールしたアプリケーションのパスはメモしておきましょう。

　※複数のアプリをインストールして配信することも可能です。

主な基本設定とアプリのインストールが完了

３．イメージを作成・登録
基本設定とアプリのインストールが完了したら、イメージ化を実施します。

※先ほどメモしたパスをLaunch Pathに入力してください。

Image Assistantを起動し、配信するアプリを選択

アプリを選択し、Launchを押下

AWSコンソールに表示されるイメージ名を入力後、イメージを作成

イメージ化中（アプリの容量によって待機時間が異なる）

イメージ作成完了

これでイメージの作成が完了しました。

次はこのイメージをどのようにユーザーに展開するかを決めます。

４．フリートを作成
接続数やインスタンスタイプ、スケーリング設定を決定します。

主な設定

• Minimum capacity（最小接続数）
  • フリートの常時起動台数を指定する項目
  • 設定値が高いほど、未使用時でも料金が発生
• Maximum capacity（最大接続数）
  • フリートの最大接続台数を指定する項目
  • 設定値以上の接続依頼があった場合、ユーザは接続不可となる
• Images（イメージ）
  • イメージビルダー内で作成したイメージ「test-image」を選択
• ネットワーク
  • フリートからインターネットに出れるような構成にする
  • サブネットは２つ指定必須（障害時の切り替えやスケーリングのために複数AZ構成を取る必要があるため）　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　etc...

追加設定

• IAMロール
  • AppStreamからAWSサービスを操作したい場合は設定
  • AppStream用のポリシー（AmazonAppStreamFullAccess）などが付与されているロールを選択
• Active Directory
  • フリートを組織のActive Directoryに参加させたい場合は設定

その他、フリートのスケーリング設定やセッション維持時間なども設定できますが、詳細は割愛します。

フリート名、接続時間、接続台数を設定

作成したイメージの選択

フリート構築中（アプリの容量によって待機時間が異なる）

フリート構築完了

フリートの構築が完了しました。

これで、イメージをどのように配信するか、決めることができました。

次は、ユーザーが利用できる範囲を指定します。

５．スタックを作成
ユーザに配信するアプリや設定、コピー＆ペーストやファイル転送などの操作可否を定義します。

主な設定

• フリート
  • 使用するフリートを選択（後から変更が可能）
• クリップボード
  • コピー＆ペーストを許可する場合は選択
• タイムゾーン
  • リモートセッションのタイムゾーンをローカルにするか否か選択

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　etc...

スタック名、作成したフリートを選択

クリップボードの設定、タイムゾーンの設定を選択

スタック構築完了（ほぼ待機時間なしで構築が終了）

スタックの作成が完了しました。

６．ユーザープールの作成

イメージの配信方法を決めたフリートと

ユーザーの利用範囲を設定したスタックが作成完了した後、

利用するユーザーを登録します。

登録内容

• Email
• First name
  • 名前をローマ字で入力
• Last name
  • 苗字をローマ字で入力

登録情報を入力

作成完了

ユーザープールの作成が完了しました。

登録したメールアドレス宛に初回パスワードが記載されたメールが届いているか確認します。

AWSからの自動送信メール

７．スタックを割り当て

作成したユーザープールとスタックを連携させ、ユーザーへアプリの配信を開始します。

連携はスタックの画面にて行います。

１ユーザに複数のスタックを割り当てることも可能です。

ユーザーに配信したいスタックを選択

割り当て完了

これで、AWS側の構築作業は終了です。

さっそく、AppStreamへ接続してみましょう。

８．AppStreamへの接続

AWSから自動で送信されたメールを確認し、ログインURLを選択してください。ログインすると以下の画面が表示されます。（初回ログイン時はパスワードの変更を求められます。）

ログイン後、AppStreamの画面

利用したいアプリ、VSCodeを選択します。

接続後、アプリが配信されている画面

接続できました！

これでVSCodeが利用できます！

案件で分かった注意ポイント

• ユーザープールの削除はコマンドから
  • ユーザープールの削除は、コンソールから実施できない　
  • CloudShellからコマンドを実行し、削除する必要がある
• スケーリング設定は適切に
  • フリートは、最小起動台数と最大起動台数が設定できる
  • 最小台数（＝常時起動台数）を多くしすぎると、利用が少ない時でもコストがかかる

• サービスクォータの上限
  • AppStreamには利用できるリソースに上限数がある（稼働可能なフリート数やユーザプールに登録できるユーザ数など）　
  • 必要に応じサービスクォータにて、AWSへ上限緩和申請を行う必要がある（事前に上限数と、必要になるリソース数を確認しておく）
• アプリの更新時はイメージの再作成が必要
  • イメージビルダー内でイメージ化したアプリをユーザーに配信している
  • アプリを更新したい場合、イメージビルダーから再度、イメージを作成する必要がある（実際の運用では、イメージ更新のタイミングなどを取り決めておくとよい）

まとめ

今回は、Amazon AppStream 2.0 の概要と最低限必要な構築ステップを紹介しました。
AppStreamは、適切に構成すればとても便利にアプリを配信できるサービスです。

本章では紹介しませんでしたが、「セッションスクリプト」という設定もあります。（ユーザーのストリーミングセッションが開始される前に、セッションスクリプトを使用して AppStream 2.0 環境を準備できるもの）

それらを使用し、よりニーズにあった利用ができるとよいですね。

参考サイト

https://d1.awsstatic.com/webinars/jp/pdf/services/20191126_AWS-BlackBelt_AmazonAppStream2.0.pdf

Amazon AppStream 2.0 とは何ですか? - Amazon AppStream 2.0

Workshop Studio

Amazon AppStream 2.0 Service Quotas - Amazon AppStream 2.0

この記事を書いた人

ニックネーム：NN
経歴：入社3年目です。主にAWSのインフラ案件に携わってきました。最近はBIツールにも触れています。
一言：港町や海沿いの風景が好きです。写真は、横浜の海を撮影したものです。神戸や熱海、舞浜のあたりも好きです。

＼DX推進・AI導入支援なら、株式会社シー・エス・エスへ／

Amazon CognitoとPythonで簡易的なシングルサインオンを実現する

こんにちは、デジタル戦略開発課のaaです。
本日は、スキルチェンジプロジェクトを経て、実業務においてAmazon Cognitoを利用する機会がありましたので、使用した際の手順について解説します。

１．Amazon Cognitoとは

Amazon Cognitoとは、アプリケーションの認証・認可を行うためのフルマネージドサービスです。
ユーザーのアカウント管理やアクセス制御（認証・認可）をAWS側で自動的に処理してくれます。さらに、Google・Amazon・Facebookなどの外部IDプロバイダーと連携できるため、たとえばGoogleアカウントを使ったログイン機能も簡単に実装できます。また、多要素認証（MFA）などの高度なセキュリティ機能にも対応しており、柔軟かつ安全なユーザー認証環境を構築できます。

２．今回どのように使用したか

今回は、別のシステムから認証サーバを経由して接続してきたアカウントに対し、再度認証を求めることがないようにするため、Cognitoを活用しました。すなわち、シングルサインオンの動作を実現させることが、目的になります。

既に認証済となっているアカウントであるため、自システムに対する認証（トークン発行）の際に、操作者側へのメールによる登録通知やパスワード再設定通知などをしないような実装を行っています。

３．実施手順

3-1.アカウントが既に登録されているか検索

    cognito_client = boto3.client("cognito-idp")

    # 連携アカウントをユーザ名として使用

    filter_str: str = 'username = "linked_account"'

    list_users_params: ListUsersRequestRequestTypeDef = {

        "UserPoolId": userpool_id,

        "Filter": filter_str,

    }

    res: ListUsersResponseTypeDef = cognito_client.list_users(**list_users_params)

    if not res["Users"]:

        # ユーザが存在しない

        return None

3-2.登録されていない場合、アカウント登録を行う

    cognito_client = boto3.client("cognito-idp")

    # 内部利用仮パスワード設定

    password = create_random_password()

    # ユーザ登録

    admin_create_user_params: AdminCreateUserRequestRequestTypeDef = {

        "UserPoolId": userpool_id,

        "Username": user_id,

        "TemporaryPassword": password,

        "MessageAction": "SUPPRESS",

    }

    cognito_client.admin_create_user(**admin_create_user_params)

    # パスワード設定

    admin_set_user_password_params: AdminSetUserPasswordRequestRequestTypeDef = {

        "UserPoolId": userpool_id,

        "Username": user_id,

        "Password": password,

        "Permanent": True,

    }

    cognito_client.admin_set_user_password(**admin_set_user_password_params)

3-3.トークンの取得を行う*1

 

 

    admin_initiate_auth_params: AdminInitiateAuthRequestRequestTypeDef = {

        "UserPoolId": userpool_id,

        "ClientId": client_id,

        "AuthFlow": "ADMIN_USER_PASSWORD_AUTH",

        "AuthParameters": {

            "USERNAME": user_id,

            "PASSWORD": password,

        },

    }

    cognito_client = boto3.client("cognito-idp")

    return_data: AdminInitiateAuthResponseTypeDef = cognito_client.admin_initiate_auth(

        **admin_initiate_auth_params

    )

 

４．最後に

今回のAmazon CognitoとPythonで簡易的なシングルサインオンを実現したプロジェクトでは、使用する前にそれをどのように使うかを実際に検証する機会となりました。特に、ユーザー登録後の確認ステータスの違いや、通知メールのカスタマイズ方法、そして3種類あるトークンの各用途に応じた使い分けについて、深く理解することができました。

５．参考

docs.aws.amazon.com

docs.aws.amazon.com

*1:トークン情報("AuthenticationResult")から"IdToken"：IDトークンを取得 (他に"AccessToken":アクセストークン、"RefreshToken":リフレッシュトークンあり)

＼株式会社シー・エス・エスは、新しい仲間を募集中♪／
資格取得も支援しています！詳しい職種紹介・募集要項はリクルートサイトへ

６．この記事を書いた人

ニックネーム：aa
経歴：入社25年目となります。主に金融・証券・銀行系のシステム開発運用業務に携わってまいりました。現在は金融系のシステム保守開発に従事しております。
一言：健康管理には気を付けたいと思っております。

AWS LambdaとPythonで実現するPDF編集 ~reportlabとpypdfを活用した実務解説~

こんにちは、株式会社シー・エス・エス、デジタル戦略開発課のaaです。
本日は、スキルチェンジプロジェクトを経て、実業務において、AWS Lamda(Python)での開発機会がありましたPDF編集について解説します。

１．仕様要件

前提条件

・編集元のPDFファイル(雛形ファイル)があること。
・S3が利用可能なこと。

　(雛形ファイルのダウンロード、作成ファイルのアップロードに使用)

環境

・Python　3.10.11

・reportlab　4.0.0*1

・pypdf　3.11.0*2

ライブラリインストール手順

pipとsetuptoolsの更新

python -m pip install

ライブラリのインストール

pip install reportlab pip install pypdf

２．実施手順

2-1.雛形ファイルをダウンロード

import boto3

    s3_client = boto3.client("s3")

    s3_client.download_file(buket, s3downfile_name,temp_pdf)

※事前にS3バケットに編集元のPDFファイル(雛形ファイル)のアップロードが必要  

2-2.編集内容を記載したPDFファイル作成

キャンパスを作成し表示したい内容を座標指定で配置

※詳細は3.PDF編集についてを参照

2-3.雛形ファイルと作成したファイルを重ね合わせPDFファイルを作成

from pypdf import PdfReader, PdfWriter

    # テンプレートPDFファイル(雛形ファイル)

    back_ground_obj = open(temp_pdf, "rb")

    back_ground = PdfReader(back_ground_obj)

    page1 = back_ground.pages[0]

   

    # 編集内容を記載したPDFファイル

    fore_ground_obj = open(make_pdf, "rb")

    fore_ground = PdfReader(fore_ground_obj)

    page1.merge_page(fore_ground.pages[0])

    # 重ね合わせたPDFファイル

    output = PdfWriter()

    output.add_page(page1)

    outputStream = open(overlay_pdf, "wb")

    output.write(outputStream)

    back_ground_obj.close()

    fore_ground_obj.close()

    outputStream.close()

※1～3を作成するPDFファイル分実施

PDF上書きイメージ図

2-4.作成したPDFファイルを1ファイルに結合

from pypdf import PdfFileMerger

    merger = PdfMerger()

    # 統合するPDFファイル

    merger.append(overlay_pdf_A)

    merger.append(overlay_pdf_B)

    merger.append(overlay_pdf_C)

    # 統合したPDFファイル

    merger.write(pdf_mergefilename)

    merger.close()

2-5.完成したPDFファイルをアップロード

import boto3

    s3_client = boto3.client("s3")

    s3_client.upload_file(pdf_mergefilename, buket, s3upfile_name)

３．PDF編集について

〇 キャンバス作成(ページ全体設定)

    # 保存先/用紙サイズ

    pdf_canvas = canvas.Canvas("保存先ファイル名", pagesize=(210 * mm, 297 * mm))

    pdf_canvas.setAuthor("作者")

    pdf_canvas.setTitle("表題")

    pdf_canvas.setSubject("件名")

〇 フォント、サイズ指定

    #  フォント、サイズ

    pdf_canvas.setFont("HeiseiKakuGo-W5", 12)

　フォント指定について*3

〇 色指定

    #  色(RGB)

    pdf_canvas.setFillColorRGB(float(0)/255,float(0)/255,float(0)/255,float(1))

〇 テキスト等、オブジェクトの配置は座標指定

    #  テキスト等、オブジェクト

    pdf_canvas.drawString(x * mm, y * mm, "表示内容")

　用紙の座標指定は左下が起点 (A4縦の場合、用紙の左上角の座標は0 , 297 * mm)*4

〇 表(テーブル)

テーブル装飾イメージ図

    # ＜縦3行・横5行のケース＞

    # 表示内容指定

    data = [

        ["項目1","項目2","項目3","項目4","項目5"],

        ["項目6","項目7","項目8","項目9",""],

        ["","項目12","","",""],

        ["","項目17","項目18","項目19",""],

    ]

    # 「項目」にテキストボックスを指定すれば、テーブル項目内の範囲で自動改行

    # テーブル列行のサイズ指定

    table = Table(

        # 表示内容

        data,

        # 各列サイズ

        colWidths=(17 * mm,11 * mm,15 * mm,20 * mm,18 * mm),

        # 各行サイズ

        rowHeights=(38 * mm,40 * mm,50 * mm,42 * mm),

      )

    # テーブルの装飾指定(フォント、枠線、色、結合、表示位置等)

    # 「項目」がテキストボックスの場合はテキストボックス装飾で指定

    table.setStyle(

        TableStyle(

          [

              # フォント・サイズ指定

              ("FONT", (0, 0), (-1, -1), "HeiseiKakuGo-W5", 10),

              # 罫線・色指定

              ("GRID", (0, 0), (0, 0), 1,   colors.black ),

              ("GRID", (2, 0), (2, 0), 1,   colors.black ),

                # 外枠・色指定

              ("BOX", (0, 0), (-1, -1), 1,  colors.black ),

              # 縦線・色指定(左右上下)

              ("LINEBEFORE", (4, 0), (4, 3), 1, colors.black ),

              ("LINEBEFORE", (3, 3), (3, 3), 1, colors.black ),

              ("LINEAFTER", (0, 1), (0, 3), 1,  colors.black ),

              ("LINEABOVE", (1, 3), (3, 3), 1,  colors.black ),

              ("LINEBELOW", (1, 1), (1, 1), 1,  colors.black ),

              # 背景色

              ("BACKGROUND", (2, 0), (2, 0), colors.aqua),

              # 結合

              ("SPAN", (0, 1), (0, 3)),

              ("SPAN", (1, 2), (3, 2)),

              ("SPAN", (4, 0), (4, 3)),

              # 表示位置(上付・中央・下付、左寄・中央・右寄)

              ("VALIGN", (4, 0), (4, 3), "TOP"),

              ("VALIGN", (1, 2), (3, 2), "MIDDLE"),

              ("VALIGN", (0, 1), (0, 3), "BOTTOM"),

              ("ALIGN", (0, 1), (0, 3), "LEFT"),

              ("ALIGN", (1, 2), (3, 2), "CENTER"),

              ("ALIGN", (4, 0), (4, 3), "RIGHT"),

            ]

        )

    )

    # テーブル書出し(範囲、位置指定)

    table.wrapOn(pdf_canvas, (20 * mm, 100 * mm))

    table.drawOn(pdf_canvas, (20 * mm, 100 * mm))

〇 テキストボックス(テーブルの項目に指定した場合、テーブル項目内で自動改行)

    # オブジェクト定義

    style_dict = {

    # フォント

    "fontName": "HeiseiKakuGo-W5",

    # サイズ

    "fontSize": 8,

    # 段落内の行間

    "leading": 8,

    # 書出しのインデント

    "firstLineIndent": 0,

    # 表示位置

    "alignment": TA_LEFT,

    }

    # 装飾定義

    style = ParagraphStyle(**style_dict)

    # テキストボックス

    text_box = Paragraph("テキストボックス表示内容", style)

〇 円、楕円

    # 楕円(座標⇒左下位置、右上位置)　

    pdf_canvas.ellipse(x * mm,y * mm, x * mm,y * mm,)

    # 円(中心座標、半径、枠線描画、塗潰し有無)　

    pdf_canvas.circle(x * mm, y * mm, r * mm, stroke=1, fill=0)

４．最後に

GUIで直感的に帳票生成するのではなくコードからPDFを生成するため、表示する内容や編集(装飾)内容についての簡易的な設計書を作成することにより、生成PDFを明確にイメージできるようにしました。また、表示内容を配置する座標位置を把握するのが手間でしたが、PDF標準ツールの「ものさし」使用することにより大まかな位置関係を把握することができました。

５．参考

docs.reportlab.com

６．この記事を書いた人

ニックネーム：aa
経歴：入社25年目となります。主に金融・証券・銀行系のシステム開発運用業務に携わってまいりました。現在は金融系のシステム保守開発に従事しております。
一言：健康管理には気を付けたいと思っております。

*1:web画面などをPDF化するのではなく、用紙形式のPDFファイルを編集する対応を前提としています。

　　従って、コードからPDFに変換するreportlabを使用します。

*2:ファイルの結合、上書きにはpypdfを使用します。
　　本紙利用において支障はないですが、最新バージョンは3.17.1　-2023.11.24現在-

*3:予め組み込まれた日本語フォントは、「HeiseiMin-W3」と「HeiseiKakuGo-W5」。

　　標準フォント以外のフォントは、登録することで使用可能。

*4:設定で逆(左上)にすることも可能(Canvas作成時、bottomup=Falseを指定)

　　また、単位はpx（ピクセル）だがmm(ミリメートル)を値に乗算することでmm指定可能

QuickSightのハンズオン ～初心者におすすめ3選～

みなさん、こんにちは。テクノロジー・コンサルティング部のなっちゃんです。
2024年8月から現在の部署に配属されたばかりの新卒社会人です。
私は大学時代に生物系を専攻しており、プログラミングも高校の情報の授業でやったきりという全くの未経験でIT企業に入社しました。

4か月の研修を経て、初めて配属された案件で使用していたAWSのAmazon QuickSight（以下：QuickSight）というBIツールの学習方法について、まとめたいと思います。

まずはBIツールとは何なのか説明していきます！

BIツールとは

BIツール (BI：Business Intelligence)とは、企業に蓄積された膨大なデータを分析・可視化し、企業の意思決定に役立てるアプリケーションソフトウェアの総称です。

BIツールとは？導入すると何ができる？(https://blog.css-net.co.jp/entry/2021/01/28/141801)より参照

ビジネスにおいて、企業が競合他社との差別化を図るためには、蓄積したデータを効率的に活用する必要があります。これまで多くの企業でデータ分析に活用されてきたExcelは表計算ソフトであるため、分析には限界があります。そこで、簡単に、より高度な分析ができるBIツールが注目されています。

従来は専門的な知識を必要とした分析作業が、BIツールでは誰でも簡単に扱えるように設計されており、データの可視化が容易にできます。したがって、複雑な情報の理解・分析が容易になり、データに基づく正確な意思決定ができるようになります。加えて、従来のExcelによるデータ分析と比べて、分析にかかる時間や人件費を大幅に削減し、業務の効率化が実現します。

このように、BIツールはデータを活用した戦略的な意思決定を可能にし、企業の競争力を高める重要な要素となっています。

QuickSightとは

QuickSightとは、AWSで利用できるBIサービスです。
BIツールは様々な種類がありますが、QuickSightの特徴は、ほかのAWSのサービスと連携しやすいことがあげられます。
下の画像はQuickSightが取り込めるデータ形式で、オレンジ色の部分がAWSのサービスとなっており、多くのAWSサービスと連携できることがわかります。

そもそもAWSって何？AWSのサービスと連携できることの何がいいの？と思うかもしれません。これは以前のブログに記載してあるのでこちらをご覧ください↓

AWSというクラウドサービスは何がすごいのか？わかりやすく初心者さんに解説blog.css-net.co.jp

QuickSightの学習に使用したハンズオン

今回私が使ったハンズオンは以下の3つです！

1.Amazon QuickSight - Visualization Basics (Japanese)

2.QuickSight 販売管理ダッシュボード編

3.Amazon QuickSight埋め込みハンズオン

学習期間は約1か月。各ハンズオンについて何を意識して勉強をしていくと良いかなど記述していきたいと思います。

1.Amazon QuickSight - Visualization Basics (Japanese)

このハンズオンでは「基本的な分析」と「高度な分析」の二部構成になっています。
QuickSightで使用される用語の学習から始まるため、QuickSightを学ぶ際は、最初にこのハンズオンを始めると良いと思います。用語の意味を知るだけではイメージがつきづらいかと思いますが、データソースとデータセットの違いや、分析とダッシュボードの違いなど、似たような用語の意味を区別して理解することが重要です。
このハンズオンを理解することで、QuickSightの基礎から応用までの使い方を身につけることができます。高度な分析については、より複雑な機能の紹介が多いため、時間がある方は高度な分析にも挑戦すると良いと思います。
Amazon QuickSight - Visualization Basics (Japanese)はこちら

2.QuickSight 販売管理ダッシュボード編

このハンズオンは「1.Amazon QuickSight - Visualization Basics (Japanese)」よりも簡単で、基礎の範囲を学べます。用語の説明はありませんが、細かく丁寧な指示が書かれているため、とてもわかりやすかったです。加えて、2のハンズオンでは、1のハンズオンにはないナビゲーションアクションやドリルスルー機能を学ぶことができます。QuickSightを使用するにあたって基本的に必要な知識をカバーしているため、良い復習になります。
QuickSight 販売管理ダッシュボード編はこちら

3.Amazon QuickSight埋め込みハンズオン

このハンズオンは、コマンドでデータの紐づけや複数ユーザーの権限などを操作する内容です。QuickSightは主にUI操作で利用するため、コマンドを覚えなくても大丈夫です。こういうやり方もあるんだな程度に覚えておいてください！
このハンズオンでは、コマンドがどのような処理を行っているのか、権限の違いが表示にどのように影響するのかを意識して学ぶと良いです。QuickSightを利用する際にはユーザ権限の設定が重要で、それぞれの権限によって見え方が変わるため、権限の意味や各権限で実現できることについても理解を深めることが大切です。
Amazon QuickSight埋め込みハンズオンはこちら

ハンズオンを行った感想

全体を通して、特に詰まることもなくスムーズに進めることができました。どのハンズオンでも、データセットの作成や簡単なビジュアル（例えば棒グラフなど）の作成といった基礎的な内容が含まれており、繰り返し実践することで知識が身に付きました。

しかし、実際の業務は一筋縄にはいきませんでした。
ハンズオンでは、QuickSightに適した階層構造がしっかりと構築されたデータを使用していたため、表の作成が非常にスムーズだったことに対し、実際の業務では、QuickSightを使用することを前提にデータが設計されていないケースが多かったためです。

業務で求められる表やグラフを作成するために必要な技術は、まずQuickSightの機能をしっかりと把握し、それをどのように活用できるかを考えることです。QuickSightが提供するさまざまなグラフ表示機能や計算フィールド、フィルター機能を駆使し、要件に合った表を作成する方法を柔軟に考えることが求められます。それでも難しい場合は、QuickSightだけでなく、他のAWSサービスを利用してデータを事前に加工する方法も検討できます。例えば、AWS Glueを使ってデータを整形したり、AthenaでSQLクエリを実行してデータを抽出したり、Redshiftを利用してデータの前処理を行ったりすることが可能です。

Amazonが提供するハンズオンには、ほかのサービスとの連携方法が学べるものも存在します。AWSは各サービスに無料利用枠が設定されているため、興味があれば下記のハンズオンにもチャレンジしてみてください！

AWS Hands-on for Beginners 手を動かしながら学ぶAnalyticsサービス入門
Glue DataBrew ハンズオン

最後に

今回は、IT未経験新卒のQuickSightの学び方として、QuickSightのサービスのみで完結するハンズオンを3つ紹介しました。

1.Amazon QuickSight - Visualization Basics (Japanese)
2.QuickSight 販売管理ダッシュボード編
3.Amazon QuickSight埋め込みハンズオン

どれもわかりやすく記載されているため、初心者でも取り組みやすいハンズオンになっているのでオススメです！

最後までお読みいただき、ありがとうございました。

＼クラウドエンジニア大募集／

この記事を書いた人

ニックネーム
なっちゃん
経歴
入社1年目
大学時代は大腸菌の代謝の研究をしていました！
実は学部生で論文を投稿するほどまじめに頑張ってました。
現在は、AWSのQuickSightを用いた業務に携わっています。
一言
画像は我が家の愛犬です！
在宅の時は癒されながら仕事しています♡

AWSというクラウドサービスは何がすごいのか？わかりやすく初心者さんに解説

皆さんこんにちは。デジタル・マーケティング部のサットンです。弊社はAWSサミットにも出展したことがある、AWSのパートナー企業なので、今回は、AWSは何がすごいのかについて記事を書いていこうと思います。
AWS初心者さんでもわかりやすいように書いていきますね。AWSのすごさの前に、AWSとは何か、AWSの基本や、クラウドというものについてもおさらいしていきます。AWSのメリット・デメリットにも触れますので、最後までお読み頂ければ嬉しいです。

AWSの基本知識

AWSとは何か

AWSとは、Amazon Web Services, Inc. が提供するクラウドコンピューティングサービスのこと

AWSとはAmazon Web Servicesの略で、Amazonのビジネス課題を解決するために生まれた、クラウドコンピューティングサービス(以下クラウドサービス)※の総称です。世界中の企業やスタートアップで利用されています。
AWSは、サーバー、ストレージ、データベース、ネットワーク、分析、機械学習など、幅広いサービスを提供しており、これらを組み合わせることで、企業側は様々なアプリケーションやサービスを構築することができるんです。

※クラウドサービスとは、インターネットを通して様々な機能を利用できるサービスです。

あのNetFlixやPayPayもAWSを使っている！

AWSが使われているサービスには、どんなものがあるのでしょうか？
実は、NetflixやPayPayなど、けっこう身近なサービスに、AWSは使われているんです。NetflixはAWSのクラウドインフラを利用することで大規模なデータストリーミングを実現していますし、PayPayが大量のトランザクションデータを処理し迅速に決済を行うことができるのは、AWSを利用しているからなんです。

クラウドサービスのすごいところ

革新的なサービス登場の基盤になっている！

クラウドサービスを提供しているのはAWSだけではありません。他にもGoogle CloudやMicrosoft Azureなどのクラウドサービスがあります。

クラウドサービス全般に言えるすごいところは、革新的なサービス登場の基盤になっていることです。NetflixやPayPayは先に述べましたが、一般人でも簡単に物が売れるメルカリ、コロナ渦でいっきに日本でもスタンダードになったウーバーイーツなども、クラウドサービスがあったからこそできたサービス。
また、クラウドに後押しされた技術も多いんです。それが、データ分析やIot、AIなど。クラウドのおかげで、私たちの生活はどんどん進化していますね。

AWSのすごいところ

そんなすごいクラウドサービスを提供するAWS。AWSの他にも優良なクラウドサービスはありますが、いったいAWSの何がそんなにすごいのでしょうか？
AWSのすごいところをご紹介します！

クラウド市場で世界No.1のシェアを誇る！市場リーダー

AWSは、2006年にサービスを開始し、クラウドサービスの先駆者として市場をリードしてきました。長年にわたる経験と実績により、多くの企業がAWSを信頼、その広範な導入が進んだ結果、クラウド市場で最大のシェア※を誇っており、幅広い採用と高い信頼性を示しています。
何においても1番を取ることは難しいし大変なことです。世界で最も利用されているクラウドサービスがAWSというのは、これはAWSのすごいところですね。

※調査会社の米Synergy Research Groupは、2023年第4四半期のグローバルにおけるクラウドインフラのシェアを下記の通り発表しています
Cloud Provider Market Share Trend

サービスの種類が多い

AWSは、機械学習、ロボット工学、量子テクノロジー、人工衛星などの最先端技術を含む200以上の様々なサービスを提供し、ほぼすべてのビジネスニーズに対応しています。サービスの種類が多い他クラウドサービスもありますが、AWSも比較的種類が豊富なクラウドサービスです。
200以上のサービスを提供しているというのは、AWSのすごいところではないでしょうか。

頻繁にサービスや機能のアップデート、改善を行っている

AWSは、年間3,000回以上のバージョンアップや機能改修を行っています。年間アップデート回数を非公開にしているクラウドサービスもありますので、年間3,000回と公開しているAWSは、このアップデート回数に自信があるのでしょうね。
また、AWSが提供する90％以上のサービスや機能は、ユーザーからのリクエストをもとに実装されていて、バージョンアップや機能改修などのアップデートについても、ユーザーからのフィードバックをもとに行われています。お客様ファースト、問題解決ファーストを掲げているのも、AWS人気の秘密かもしれません。
このようにAWSは、毎年多数の新サービスと機能を発表し続けていて、クラウドテクノロジーの最前線に立っています。この迅速な革新サイクルがあるからこそ、企業は最新の技術を活用して競争力を維持できるんですね。多くの企業がAWSを選ぶ理由がわかる気がします。

AWSのメリットとデメリット

AWSのすごいところを踏まえたうえで、メリットとデメリットも挙げておきたいと思います。

メリットは低コスト

AWSは初期費用が無料です。また、AWS内のほとんどのサービスが従量課金制ですので、無駄なコストも抑えられます。プランやサービスによって初期費用が発生したり従量課金制ではないクラウドサービスもあるので、そういったところと比べると、コストを抑えてクラウド導入できる点は良いですね。

デメリットはベンダーロックイン

ベンダーロックインという言葉を聞いたことはありますか？
ベンダーロックインとは、特定のベンダー※の製品やサービスに依存してしまい、他ベンダーに切り替えることが難しくなってしまう現象のことをいいます。
AWSに依存しすぎると、AWS以外のクラウドサービスに移行できなくなってしまいますよーということですね。ただこれはAWSに限った話ではなく、クラウドサービス全般にいえる話になります。どこのクラウドサービスを選んでも、結局はベンダーロックインに陥りやすくなります。
※ベンダーとは販売業者という意味で、消費者に対してサービスの提供を行っている企業のこと

AWSのすごいところ まとめ

いかがでしたでしょうか。実はだまだAWSのすごいところはあります。非常に高いセキュリティ基準と多数のコンプライアンス認証を持っていたり、世界中に20以上のリージョンと60以上のアベイラビリティゾーンを持ち、地理的に分散したデータセンターを提供していたり...などもAWSのすごいところとして挙げられるのですが、まぁセキュリティやデータセンター分散などは、他クラウドサービスだってみんなすごいので、AWS独自のすごいところとしては弱いのかなと思います。

AWSのすごいところは、
1.クラウド市場で世界No.1のシェアを誇る、市場リーダーであること！
2.サービスの種類が200以上と多いこと！
3.サービスや機能のアップデートや改善が比較的多いこと！
この3点がメインだと感じています。

いかがでしたでしょうか。AWS何がすごいのか、なんとなくおわかりいただけましたか。
AWS以外にもたくさんのクラウドサービスがありますので、企業で導入を考える際にはすごいところだけに惑わされずに、じっくり検討してくださいね。
最後までお読み頂き、どうもありがとうございました！

 

クラウドに関して何かお悩みがあれば、お気軽にお問い合わせくださいね。
無料相談受付中です！

 

【関連記事】

blog.css-net.co.jp

この記事の担当

デジタル・マーケティング部

ニックネーム：サットン
好きなもの：犬、古畑任三郎、音楽
一言：高校時代にガールズバンドを組んでいました。カラオケの十八番は、相川七瀬の夢見る少女じゃいられないです！

【AWS】Amazon S3 オブジェクトロック有効時のライフサイクルルールについて

みなさん、こんにちは。TC部所属のsr2525です。

今回はAmazon S3（以下S3）について、私が悩んだ点についてご紹介させていただきます。

それは、表題にもある「オブジェクトロック有効時のライフサイクルルールについて」です。
オブジェクトロック有効時にどのようにライフサイクルルールを設定すれば、望んだ期間経過後にオブジェクトを削除できるのか、バージョニングとの兼ね合いは、など実際に検証した結果をまとめながら共有させていただこうと思います。

1.オブジェクトロックとは

S3にあるオブジェクトを削除/上書きできないように保護する設定です。
操作ミスでの誤った削除/上書き、悪意を持った削除/上書きを防止します。

オブジェクトロックについてのAWS公式ドキュメントは以下です。
docs.aws.amazon.com

2.ライフサイクルルールとは

S3にあるオブジェクトを別のストレージクラスに移動したり、一定期間経過後に削除するときに使用する設定です。

ただし、オブジェクトロックが有効の場合、ライフサイクルでは完全に削除されず削除マーカーが付与され論理削除の状態となります。（削除マーカーが現行バージョンとなり、対象のオブジェクトは非現行バージョンとなり残る）
非現行バージョンについては、オブジェクトロックの保護期間が過ぎたものについては完全に削除が可能です。
このあたりは設定時に注意が必要です。

ライフサイクルルールについてのAWS公式ドキュメントは以下です。
docs.aws.amazon.com

それでは設定をしていきましょう。

3. オブジェクトロックの設定

S3 バケット作成時はオブジェクトロックの有効/無効のみ設定することができます。
バケット作成後にも設定することができるので、バケット作成時に必ず有効にしなくても問題ありません。

このほかに、保持期間や保持モードを設定する必要がありますが、バケット作成後に設定することができます。
具体的には「対象のバケット > プロパティタブ > オブジェクトロック」にて設定を行います。
今回の設定値は以下になります。

それぞれの設定項目の説明は以下になります。
※詳細は上述の公式ドキュメントを参照してください。
・オブジェクトロックの有効/無効
オブジェクトロックの有効/無効を設定します。
※一度オブジェクトロックを有効にすると、無効化にすることはできないので注意
有効にする場合、S3 バケット全体に影響するため了承のチェックをします。
・デフォルトの保持
有効にするとオブジェクトを削除/上書きから保護します。
・デフォルトの保持モード
以下２種類のモードがあります。
ガバナンス：特定のIAMアクセス許可を持つユーザーであれば、保持期間中であってもオブジェクトの削除/上書きが可能
コンプライアンス：保持期間中オブジェクトの削除/上書きは全ユーザー不可
・デフォルトの保持期間
オブジェクトを保持する期間を指定します。（日 or 年）

4. ライフサイクルルールの作成

次にライフサイクルルールを作成していきます。
以下の2つのルールを作成します。

1. オブジェクトを削除するためのルール
2. 有効期限切れのオブジェクト削除マーカーを削除するルール

4-1.オブジェクトを削除するためのルール

オブジェクトが作成されてから削除するまでの期間を設定します。
具体的には「対象のバケット > 管理タブ > ライフサイクルルール」にて設定を行います。
今回の設定値は以下になります。

ここで注意が必要なのが、オブジェクトロックの保持期間との関係です。
オブジェクトロックの保持期間とライフサイクルの完全削除のタイミングが被らないようにしましょう。
理由は、オブジェクトロックの保持期間中は、ライフサイクルルールの「オブジェクトの現行バージョンの有効期限が切れる」で設定した期間後に削除マーカーは付与することができますが、オブジェクトを完全に削除することはできないためです。
そのため、オブジェクトロックの保持期間が過ぎてから、オブジェクトを完全に削除するような設定をしてあげる必要があります。
今回は「デフォルトの保持期間」を「1日」としているので、ライフサイクルルールの設定値の合計は「2日」以上になるようにしました。

ここで設定中に登場していまいち何のことか分かりにくい「削除マーカー」について触れておきます。
「削除マーカー」はバージョニングが有効なバケットのオブジェクトを削除する際に付与されるもので、付与されたオブジェクトは非現行バージョンとなり論理削除された状態になります。
削除マーカーは現行バージョンとして扱われます。非現行バージョンにオブジェクトが残っているうちに削除マーカーを削除すると、論理削除が解消され対象のオブジェクトを現行バージョンに戻すことも可能です（今回はオブジェクトロックをかけているので実施不可）。
ライフサイクルルールにより削除マーカーを付与して、非現行バージョンになったオブジェクトを完全削除する、という流れになります。

4-2.有効期限切れのオブジェクト削除マーカーを削除するためのルール

先ほどの説明で「削除マーカー」は分かったけど、「有効期限切れ」とは何だ？という疑問が出た方もいるかもしれません。
「有効期限切れのオブジェクト削除マーカー」とは、非現行バージョンにあったオブジェクトが削除され、削除マーカーのみが残った状態のものをいいます。

この有効期限切れの削除マーカーを消すための設定をしていきます。
設定値は以下になります。


なぜ違うライフルサイクルルールを作る必要があるかですが、
１つ目の「オブジェクトを削除するためのルール」で「オブジェクトの現行バージョンの有効期限が切れにする」にチェックを入れていると、こちらの設定が有効にすることができないからです。
ただ、削除マーカー自体のサイズは0バイトで容量を取らないため、残っててもいいよという方は特にこの設定を入れなくても問題ありません。

5.試してみた

実際に適当なオブジェクトをこのバケットに配置して、オブジェクトが削除され、削除マーカーも削除されるまでを見ていきましょう。

5-1.オブジェクトのアップロード、設定（オブジェクトロック、現行バージョンの有効期限）の適用期間の確認

「2024/06/17 12:55:30 PM JST」にアップロードしました。
オブジェクトロックの保持期間とライフサイクルルールが適用される時間を確認しましょう。

オブジェクトロックの保持期間

ライフサイクルルールにより現行バージョンではなくなる時間（削除マーカー付与）

・オブジェクトロックの保持期間：2024/06/18 12:55:29 PM JSTまで有効
・ライフサイクルルールにより現行バージョンではなくなる時間：2024/06/19 09:00:00 AM JST
　※ライフサイクルルールは世界標準時間「00:00:00 UST」に適用されます（09:00:00 AM JST）。1日でルールを設定している場合は2日目の午前9時にルールが適用されることになります。
上記時間にオブジェクトロックが解除、削除マーカーの付与が行われて、対象のオブジェクトは非現行バージョンでいつでも削除できる状態になる予定です。（多少のラグが発生する場合もあるみたいです）

5-2.設定期間経過後

「2024/06/19 09:00:00 AM JST」にオブジェクトの状態を確認したところ以下のように、まだ現行バージョンとして残っていました。

この日は17時ごろにも確認したのですが、まだ残っていました。。。

翌日確認したところ、以下のように現行バージョンとしては消えていました。（ルール適用までだいぶラグがあるようですね）

「バージョンの表示」を選択して、オブジェクトのバージョン履歴を確認してみたところ以下のようになっていました。

• 削除マーカーが現行バージョンになっている
• もともとのオブジェクトは削除マーカーが付与されて非現行バージョンになっている

以下のドキュメントにもあるように削除キューに追加して非同期的に削除のアクションを行うようなので、時間ちょうどに消えないのは致し方ないことみたいですね。
オブジェクトの有効期限 - Amazon Simple Storage Service

非現行バージョンの完全削除は１日で設定したので、さらに翌日確認してみます。

5-3.非現行バージョンの完全削除期間経過後

確認してみると、まだライフサイクルルールが動いておらずオブジェクトが残っていました。
後日再度確認すると、以下のように削除マーカーだけが残りオブジェクトは完全に削除されていました。

この削除マーカーだけ残った状態を「有効期限切れのオブジェクト削除マーカー」と呼びます。

5-4.有効期限切れのオブジェクト削除マーカーの削除

数日経過後、確認してみると削除マーカーも完全に消えており、バケットが空の状態になっていました。

6.まとめ

設定したライフサイクルルールでS3バケット内のオブジェクトを完全に削除することができました。
ただ、ライフサイクルルールの適用には時間がかかり、想定していた時間よりも遅く削除が完了することになってしまいました。
実際にS3でオブジェクトロックとライフサイクルルールを使用するときは、このあたりを考慮する必要がありそうです。

この記事を書いた人

ニックネーム：sr2525
好きなもの：猫、KPOPなど
一言：写真は今年大洗で撮った初日の出です🌅