DevOpsチュートリアル：Docker、Kubernetes、およびAzure DevOps

この記事では、DevOpsについて学び、それがアジャイル方法論とどのように異なるかを学びます。また、人気のあるDevOpsツールとそれらがDevOpsライフサイクルで果たす役割についても取り上げます。

学ぶこと

• Docker、Kubernetes、およびAzure DevOpsとは何か
• DevOpsとは何か、なぜ必要なのか
• DevOpsとアジャイルの違いは何か
• いくつかの重要なDevOpsツールは何か
• DockerがDevOpsにどのように役立つか
• KubernetesがDevOpsにどのように役立つか
• Azure DevOpsがDevOpsにどのように役立つか
• 継続的インテグレーションと継続的デリバリー（CI/CD）とは何か
• インフラストラクチャのコードとは何か
• TerraformとAnsibleがDevOpsにどのように役立つか

Docker

Dockerは、コンテナ化されたアプリケーションを構築、テスト、展開するために使用されるオープンソースソフトウェアツールです。ところで、コンテナ化とは何ですか？コンテナ化とは、すべてのライブラリやファイルをアプリケーションコードとともに1つのユニットである「コンテナ」と呼ばれる単位にまとめて、どのようなインフラストラクチャでも実行できるようにする概念です。

Kubernetes

Kubernetesは、コンテナ化されたアプリケーションやサービスを管理するコンテナオーケストレーションシステムです。スケーリング、デプロイメント、ロードバランシングなど、コンテナ化された環境で実行されるタスクを管理します。Kubernetesはポータブルで効率的、費用対効果があり、システム統合、APIベースのサポートなどの機能を提供しています。

Azure DevOpsは、ソフトウェア開発と展開のプロセスを迅速かつ整理されたものにするさまざまなツールと機能を提供するマイクロソフトの製品です。ソフトウェア開発者、プロジェクトマネージャー、その他の貢献者が共同でソフトウェアを開発できるプロセスセットを提供します。既存のエディタやIDEに追加して、チームがあらゆる規模のプロジェクトで効果的に作業できるようにします。

シンプルなユースケースから始めましょう。

無料コース — 10ステップで学ぶ

• 10ステップでDockerを学ぶ
• 10ステップでKubernetesを学ぶ
• 10ステップでAWSを学ぶ

DevOpsとは何ですか？

ソフトウェア開発に関するほとんどのバズワードと同様に、DevOpsには受け入れられた定義がありません。

定義は以下のように単純なものから、書籍のページ全体をカバーする複雑なものまでさまざまです。

DevOpsは、組織が文化的な哲学、実践、およびツールを組み合わせ、アプリケーションやサービスを提供する能力を向上させるものです — Amazon Web Services (AWS)高速度で提供する能力を向上させるものです — Amazon Web Services (AWS)

DevOpsを定義しようとする代わりに、ソフトウェア開発がDevOpsに進化する過程を理解しましょう。

ウォーターフォールモデル

ウォーターフォールモデルは、構造化されたアプローチに従う方法論です。要件、設計、実装、テスト、展開、および保守の6つのフェーズで構成されています。各フェーズは前のフェーズの完了に基づいて構築されます。これらの段階を進む際には、以前のプロセスに戻ることなく進行し、それゆえ直線的なプロセスとなります。

ソフトウェア開発の最初の数十年は、ウォーターフォールモデルを中心に展開され、ソフトウェア開発を、例えば橋を建設する場合のようにアプローチしていました。

数週間から数ヶ月かかる複数の段階でソフトウェアを構築します。

ほとんどのウォーターフォールプロジェクトでは、ビジネスがアプリケーションの動作バージョンを見るまで数ヶ月かかることがあります。

優れたソフトウェアを構築するための主要要素

滝のようなモデルで数十年間働いてきた中で、優れたソフトウェアを開発する際のいくつかの重要な要素を理解しています：

• コミュニケーション
• フィードバック
• 自動化

コミュニケーションの重要性

人とのコミュニケーションはソフトウェアプロジェクトの成功に不可欠です。

滝のようなモデルでは、要件、設計、アーキテクチャ、展開に関する1000ページのドキュメントを作成してコミュニケーションを向上させようとしました。

しかし、時間の経過とともに、次のことがわかりました：

• チーム内のコミュニケーションを向上させる最良の方法は、チームを一緒に集めることです。そして、さまざまなスキルを持った人々を同じチームに配置することです。
• さまざまなスキルを持つクロス機能チームは非常に有効です。

早いフィードバックの重要性

迅速なフィードバックを得ることは重要です。優れたソフトウェアを構築することは、すべて迅速なフィードバックを得ることにかかっています。

• ビジネスの期待に応えるアプリケーションを構築していますか？
• 本番環境に展開された場合にアプリケーションに問題があるでしょうか？

数か月後に知るのではなく、できるだけ早く問題を見つけたいです。問題を早く見つければ見つけるほど修正が容易になります。

最良のソフトウェアチームは迅速なフィードバックを可能にするよう構成されているとわかりました。

自動化の重要性

自動化は重要です。ソフトウェア開発にはさまざまな活動が含まれます。手作業では遅くて誤りが生じやすいです。常に自動化を導入する機会を探すことが不可欠であることを理解しています。

優れたソフトウェアを開発するための主要な要素を理解したので、アジャイルとDevOpsへの進化を見てみましょう。

アジャイルへの進化

アジャイルは、段階的な進捗、頻繁なフィードバック、および開発ライフサイクルを通じての変更要件への対応能力を強調するアプローチです。アジャイルは、クロスファンクショナルなチームが短い開発サイクルで働くことを促進し、継続的な改善を促進し、エンドユーザーに迅速に価値を提供します。これは、チーム間のコミュニケーションを向上させ、フィードバックを得て自動化を導入するための進化に向けた最初のステップでした。

アジャイルはビジネスと開発チームを1つのチームに統合し、スプリントと呼ばれる小さなイテレーションで優れたソフトウェアを構築することに取り組みます。

開発の各段階に数週間または数か月を費やすのではなく、アジャイルはユーザーストーリーと呼ばれる小さな要件を開発サイクルを通じて数日で、場合によっては同じ日に取り組むことに焦点を当てています。

アジャイルは、チーム間のコミュニケーションをどのように向上させたのか？

アジャイルはビジネスと開発チームを一緒にしました。

• ビジネスは何を構築するかを定義する責任があります。要件は何ですか？
• 開発は、要件を満たす製品を構築する責任があります。開発には、ソフトウェアのデザイン、コーディング、テスト、パッケージングに関わるすべての人が含まれます。

アジャイルでは、ビジネス側からの代表であるプロダクトオーナーが常にチームと一緒におり、チームはビジネス目標を明確に理解しています。

開発チームが要件を理解せず、誤った方向に進んでいる場合、プロダクトオーナーがコース修正を手助けし、正しい方向に進むよう支援します。

結果：チームが構築する最終製品はビジネスが望むものになります。

もう1つ重要な要素は、アジャイルチームがクロス機能スキルを持っていることです：コーディングスキル（フロントエンド、API、データベース）、テストスキル、ビジネススキルが含まれます。これにより、一緒に素晴らしいソフトウェアを構築する必要がある人々の間でコミュニケーションが向上します。

アジャイルと自動化

アジャイルチームが焦点を当てる自動化領域は何ですか？

ソフトウェア製品にはさまざまな欠陥があります：

• 機能的な欠陥は、製品が期待どおりに機能しないことを意味します。
• 技術的な欠陥は、ソフトウェアのメンテナンスを難しくします。たとえば、コード品質の問題です。

一般的に、アジャイルチームは技術的および機能的な欠陥をできるだけ早く見つけるために自動化を活用することに重点を置いています。

アジャイルチームはまた、コード品質にも重点を置いています。SONARのようなツールを使用してアプリケーションのコード品質を評価します。

偉大な自動化テストと優れたコード品質チェックがあれば十分ですか？鍵はこれらのプロセスを頻繁に実行することです。アジャイルチームは継続的インテグレーションを強調し、バージョン管理へのコミットが一連のアクションをトリガーするようにします。これにはユニットテスト、自動化テスト、コード品質チェックが含まれ、すべてが連続的なインテグレーションパイプラインにシームレスに統合されます。アジャイル初期の広く採用されたCI/CDツールであるJenkinsは、これらの自動化されたプロセスを統率する上で重要な役割を果たしました。

アジャイルが即時フィードバックをどのように促進したのか？

最も重要な要素は、ビジネスが最終成果を見るために数ヶ月待つ必要がないということです。各スプリントの最後には、製品がアーキテクチャやビジネスチームを含むすべてのステークホルダーにデモされます。すべてのフィードバックが受け入れられ、次のスプリントのユーザーストーリーが優先されます。結果：チームが構築する最終製品は、ビジネスが望むものです。

即時フィードバックを可能にするもう一つの重要な要素は継続的インテグレーションです。たとえば、バージョン管理にコードをコミットしたとします。30分以内に、コードがユニットテストの失敗や統合テストの失敗を引き起こすかどうかのフィードバックを受け取ります。コードがコード品質基準を満たさないか、ユニットテストで十分なコードカバレッジがない場合にもフィードバックを受け取ります。

アジャイルは成功したか？はい。間違いなく。ビジネスと開発チーム間のコミュニケーションを改善し、さまざまな欠陥を早期に発見することを重視することで、アジャイルはソフトウェア開発を次のレベルに引き上げました。

私は素晴らしいチームと共にアジャイルを使用した素晴らしい経験をしました。私にとっては、ソフトウェアエンジニアリングは、要件からアプリケーションを本番環境に導くまでのすべての取り組みを表しており、初めてプログラミングと同じくらい楽しいものでした。

しかし、進化は止まりませんか？いいえ。

新たな課題が現れました。

マイクロサービスアーキテクチャの進化

私たちはマイクロサービスアーキテクチャに移行し、大規模なモノリスアプリケーションを構築する代わりに、いくつかの小さなAPIを構築し始めました。

新たな課題は何でしたか？

オペレーションがより重要になりました。1つのモノリスリリースを1か月に1回行う代わりに、毎週何百もの小さなマイクロサービスリリースを行っています。マイクロサービス間の問題のデバッグや、マイクロサービスの状況を把握することが重要になりました。

ソフトウェア開発における新しいバズワードの時期でした。DevOps。

DevOpsの出現

DevOpsの焦点は何でしたか？

DevOpsの焦点は、開発チームとオペレーションチームのコミュニケーションを向上させることでした。

• デプロイメントを簡単にするにはどうすればよいでしょうか？
• オペレーションチームの作業を開発チームにより見える化するにはどうすればよいでしょうか？

DevOpsはチーム間のコミュニケーションをどのように向上させましたか？

DevOpsはオペレーションチームを開発チームにより近づけました。

• より成熟した企業では、開発チームと運用チームが一つのチームとして働いていました。彼らは共通の目標を共有し始め、両チームは相手の直面する課題を理解し始めました。
• 企業において、DevOpsの進化の初期段階では、運用チームの代表者がスプリント（スタンドアップや振り返り）に関与することがあります。

DevOpsチームが焦点を当てる自動化領域は何ですか？

アジャイルの焦点領域である継続的インテグレーションとテスト自動化に加えて、DevOpsチームはサーバーのプロビジョニング、サーバー上のソフトウェアの構成、アプリケーションの展開、および本番環境の監視など、運用チームの活動の一部を自動化することに焦点を当てました。いくつかの主要な用語としては、継続的デプロイメント、継続的デリバリー、およびインフラストラクチャのコードがあります。

継続的デプロイメントは、ソフトウェアの新バージョンをテスト環境に継続的に展開することに関わります。GoogleやFacebookなど、より成熟した組織では、継続的デリバリーが本番環境にソフトウェアを継続的に展開するのに役立ち、おそらく1日に何百もの本番展開が行われます。

インフラストラクチャのコードは、インフラストラクチャをアプリケーションコードと同じように扱うことです。構成を使用してサーバーやロードバランサー、データベースなどのインフラストラクチャを自動化された方法で作成します。インフラストラクチャの変更を追跡できるように、インフラストラクチャをバージョン管理します。

DevOpsはどのように即時フィードバックを促進しましたか？

DevOpsは運用チームと開発チームを一緒にします。運用と開発が同じチームの一部であるため、全体のチームが運用と開発に関連する課題を理解しています。

• 運用上の問題が開発者から迅速な対応を受けます。
• ソフトウェアを本番環境に展開する際の課題が、早い段階で運用チームの注意を引きます。

DevOpsは継続的な統合、継続的な配信、およびインフラストラクチャのコード化を奨励しています。

• 継続的な配信のおかげで、コードの変更や構成の変更がテストやステージング環境を壊す可能性がある場合、数時間以内にわかります。
• インフラストラクチャのコード化により、開発者は自己プロビジョニング環境を作成し、コードを展開し、運用チームからの助けを借りることなく問題を見つけることができます。

私はアジャイルとDevOpsを、素晴らしいソフトウェアを構築する方法を改善する2つの段階と見ています。それらは互いに競合するのではなく、一緒に素晴らしいソフトウェア製品を構築するのに役立ちます。

私にとって、アジャイルとDevOpsの目標は次のようなことをすることです:

• ビジネス、開発、運用チーム間のコミュニケーションとフィードバックを促進する
• 自動化による痛みのポイントを緩和する。

DevOpsストーリー

以下に例を示します。

• あなたはチームのスター開発者で、迅速な修正を行う必要があります。
• GitHubリポジトリに移動します。
• プロジェクトを素早くチェックアウトします。
• ローカル環境を素早く作成します。
• 変更を行います。それをテストします。ユニットと自動化テストを更新します。
• コミットします。
• QAへの展開が完了したというメールが届きます。
• 数個の統合テストが自動的に実行されます。
• QAチームに承認を求めるメールが送られます。彼らは手動テストを実施して承認します。
• あなたのコードは数分で本番環境で稼働します。
• これが理想的なシナリオだと考えるかもしれません。しかし、Netflix、Amazon、Googleなどの革新的な企業で日々行われていることをご存知でしょうか？

これはDevOpsの物語です。

DevOps = 開発 + 運用

DevOpsはソフトウェア開発の自然な進化です。DevOpsは単なるツールやフレームワーク、あるいは単なる自動化にとどまらず、これらすべての組み合わせです。

DevOpsは人々、プロセス、製品に焦点を当てています。DevOpsの人々の部分は文化と素晴らしいマインドセットの構築についてであり、オープンなコミュニケーションを促進し、迅速なフィードバックを重視し、高品質のソフトウェアを尊重する文化です。

アジャイルはビジネスと開発チームとのギャップを埋めるのに役立ちました。開発チームはビジネスの優先事項を理解し、ビジネスと協力して最も価値のあるストーリーを最初に提供するように取り組みましたが、開発チームと運用チームは一致していませんでした。

彼らは異なるゴールを持っていました。

• 開発チームの目標は、できるだけ多くの新機能を本番環境に展開することです。
• オペレーションチームの目標は、プロダクション環境をできるだけ安定させることでした。

わかるように、本番環境への導入が難しい場合、開発とオペレーションは一致していません。

DevOpsは、開発チームとオペレーションチームを共通の目標で一致させることを目指しています。

開発チームはオペレーションチームと協力して運用上の課題を理解し解決します。オペレーションチームはスクラムチームの一部であり、開発中の機能を理解します。

これを可能にする方法は？開発とオペレーションの間にある壁を取り払うことです！

開発チームとオペレーションチームを一緒にする

オプション1

成熟したDevOps企業では、開発とオペレーションは同じスクラムチームの一部として働き、お互いの責任を共有します。

オプション2

ただし、DevOpsの進化の初期段階にいる場合、どのようにして開発とオペレーションに共通の目標を持たせ、一緒に働かせることができるでしょうか？

以下に、行うことができるいくつかの方法があります：

• 開発チームに運用チームの一部の責任を共有させる。たとえば、新しいリリースの責任を本番展開後の最初の週に開発チームが引き受けることができます。これにより、開発チームは運用が新しいリリースを稼働させる際に直面する課題を理解し、より良い解決策を見つけるために協力するのに役立ちます。
• もう1つの方法は、オペレーションチームの代表をスクラムの活動に関与させることです。立ち上がり会議や振り返り会議に参加させる。
• 次にできることは、オペレーションチームが直面する課題を開発チームにより可視化することです。オペレーションで課題に直面した場合、解決策に取り組むチームに開発チームを加えます。

どのような方法を取るにせよ、壁を取り払い、開発とオペレーションチームを一緒にする方法を見つけてください。

自動化のおかげで、別の興味深い選択肢が浮かび上がります。インフラストラクチャをコードとして使用し、開発者のためのセルフプロビジョニングを可能にすることで、オペレーションと開発チームが理解できる共通の言語、コードを作成できます。

DevOpsユースケース

以下の画像をご覧ください:

この画像は2つのシンプルなワークフローを示しています

1. TerraformとAzure DevOpsを使用したインフラストラクチャコードによるKubernetesクラスタのプロビジョニング。
2. Azure DevOpsを使用したマイクロサービスの継続的デプロイメント、マイクロサービスのDockerイメージをKubernetesクラスタにビルドおよびデプロイ。

複雑に聞こえますか？

それを分解して理解しようとしてみましょう。

まず、#2 — 継続的デプロイメントから始めましょう。

#2: Azure DevOpsとJenkinsを使用したDevOps継続的デプロイメント

素晴らしいテストやコード品質チェックを行わないと、頻繁に実行しない意味はありませんか？

ソフトウェアを頻繁にデプロイしない場合、デプロイ自動化の意味はありませんか？

開発者がコードをバージョン管理システムにコミットすると、以下の手順が実行されます:

• ユニットテスト
• コード品質チェック
• 統合テスト
• アプリケーションパッケージング — デプロイ可能なバージョンのアプリケーションを構築する。ツール — Maven、Gradle、Docker
• アプリケーションデプロイメント — 新しいアプリケーションまたは新しいバージョンのアプリケーションを本番環境に配置すること
• アプリケーションをテストするためのテストチームへのメール

テストチームからの承認が得られ次第、アプリは即座に次の環境にデプロイされる。

これを継続的デプロイメントと呼ぶ。プロダクションまで継続的にデプロイすることを継続的デリバリーと呼ぶ。

最も人気のあるCI/CDツールはAzure DevOpsとJenkinsである。

#1: DevOps インフラストラクチャをコードとして Terraform を使用

昔は、環境を手動で作成し、アプリケーションをデプロイしていた。

サーバーを作成するたびに、これを手動で行う必要があった。

• ソフトウェアのバージョンを更新する必要がある
• セキュリティパッチを手動でインストールする必要がある

手動で行うと、次のような結果が生じる：

• エラーの発生率が高い
• 複製環境が難しい

インフラストラクチャをコードとして

インフラストラクチャをコードとして — インフラをアプリケーションコードと同じように扱う。

インフラストラクチャをコードとして理解するための重要な点は以下の通りです：

• インフラチームは付加価値のある作業に焦点を当てる（ルーチン作業ではなく）
• エラーが少なく、障害からの迅速な回復
• サーバーが一貫している（構成の漂流を回避）

最も人気のあるIaCツールはAnsibleとTerraformである。

典型的には、IaCの手順は以下の通りです:

• テンプレートからサーバーのプロビジョニング（クラウドによって有効化）
• ソフトウェアのインストール
• ソフトウェアの構成

サーバープロビジョニング

通常、プロビジョニングツールは使用され、新しいサーバーをネットワーキング機能で準備します。最も人気のあるプロビジョニングツールはCloud FormationとTerraformです。

Terraformを使用すると、サーバーや負荷分散装置、データベース、ネットワーキング構成など、インフラストラクチャ全体をプロビジョニングできます。PackerやAMI（Amazon Machine Image）などのツールを使用して作成された事前作成イメージを使用してサーバーを作成できます。

構成管理

構成管理ツールは以下のように使用されます:

• ソフトウェアのインストール
• ソフトウェアの構成

一般的な構成管理ツールにはChef、Puppet、Ansible、SaltStackがあります。これらは既存のサーバーにソフトウェアをインストールおよび管理するために設計されています。

DevOpsにおけるDockerとKubernetesの役割

マイクロサービスの世界では、いくつかのマイクロサービスがJavaで構築され、いくつかがPythonで、いくつかがJavaScriptで構築されるかもしれません。

異なるマイクロサービスには、アプリケーションを構築しサーバーに展開する異なる方法があります。これはオペレーションチームの仕事を難しくします。複数のタイプのアプリケーションを展開するための類似した方法を持つにはどうすればよいでしょうか？それにDockerとコンテナが登場します。

Dockerを使用すると、言語に関係なくマイクロサービスのイメージを構築できます。これらのイメージをどんなインフラストラクチャでも同じ方法で実行できます。これにより操作が簡素化されます。

Kubernetesは、さまざまな種類のコンテナをオーケストレートし、クラスタにデプロイするのを支援することで、これを補完します。

Kubernetesは以下も提供します:

• サービスディスカバリ
• ロードバランシング
• 集中設定

DockerとKubernetesはDevOpsを簡単にします。

重要なDevOpsメトリクス

以下は、いくつかの重要なDevOpsメトリクスであり、時間をかけて追跡および改善できます。

• デプロイメント頻度 — アプリケーションがどれだけ頻繁に本番環境にデプロイされていますか？
• マーケットへのリードタイム — 機能をコーディングから本番環境へリリースするまでにどれくらい時間がかかりますか？
• 新リリースの失敗率 — リリースのうち何割が失敗していますか？
• 修正までのリードタイム — プロダクション環境の修正とリリースにどれくらい時間がかかりますか？
• 回復までの平均時間 — 重大な問題からプロダクション環境を回復するのにどれくらい時間がかかりますか？

DevOpsのベストプラクティス

アジャイルプロジェクト管理

アジャイルプロジェクト管理はソフトウェアアプリケーションを開発するための反復的なアプローチです。この方法を通じて、チームは開発スピードを向上させ、さまざまな顧客のニーズに適切に対応できます。アジャイルメソッドは、従来のウォーターフォールメソッドとは異なり、長いリリースサイクルがありました。アジャイルは、スクラムとかんばんフレームワークを使用して、クライアントのニーズに合わせてソフトウェアを提供します。

適切なツールの使用

ソフトウェア開発者やシステム管理者は、DevOpsライフサイクルの各段階で適切なDevOpsツールを選択し、使用する必要があります。高付加価値のアプリケーションを構築するために。

以下は、DevOpsエンジニア、システム管理者、および他の関係者が使用できるツールの例です。

1. Jiraのようなツールは、チームがタスクをより小さな管理しやすい部分に分割し、チームの生産性を向上させるのに役立ちます。
2. JenkinsやBitbucketなどのツールは、テストから展開フェーズまでのコードフローを自動化するのに役立ちます。
3. SlackやGetFeedbackなどのツールは、チャットツールと調査プラットフォームを統合してリアルタイムのフィードバックを収集およびレビューするのに役立ちます。

継続的インテグレーション/継続的デリバリー

継続的インテグレーション（CI）と継続的デリバリー（CD）は、組織が迅速かつ効果的にソフトウェアを出荷するのを支援する現代のソフトウェア開発プラクティスです。CIでは、開発者がアプリケーションコードを何度も共有リポジトリにコミットします。CDでは、コードが迅速かつスムーズに本番環境に配信されます。CDはまた、統合が遅延や障害なしに行われることを保証します。

セキュリティの統合

セキュリティはソフトウェア開発プロセスの重要な部分です。サイバー犯罪やデータ侵害事件が増加している現代では、組織はシステムにセキュリティを統合する重要性に気づいています。過去にはセキュリティはソフトウェア開発ライフサイクルの最終段階で考慮されることが一般的でしたが、DevSecOpsの登場により、セキュリティはアプリケーション開発の最初の日から考慮および統合されています。

オブザーバビリティは、マイクロサービスやクラウドアーキテクチャを使用する複雑なアプリケーションを開発する際に重要です。オブザーバビリティは、DevOpsチームが異なるアプリケーション（マイクロサービス、クラウドアプリなど）の複雑な構造を理解し、環境の将来のニーズに対処するのに役立ちます。KubernetesオブザーバビリティとSplunkは、最高のオブザーバビリティプラットフォームの一部です。

DevOps実装の成熟度をどのように測定しますか？

• 開発プロセスから展開までの時間は全体的に満足であるべきです
• 新しいコードの展開頻度を決定する
• インシデントや予期しないイベントからの回復時間（MTTR）は可能な限り低くするべきです
• 成功した展開は失敗した展開を上回るべきです
• 迅速かつ信頼性の高いリリースは高い投資収益率（ROI）をもたらすべきです。

DevOps変革のベストプラクティス

• リーダーシップの賛同が重要です
• 前払いコストがかかります
• チームを支援するためにCOEを設定します
• 適切なアプリケーションとチームを選択します
• 小規模から始めます
• 学びを共有します（ニュースレター、コミュニケーション、COE）
• 探求と自動化のマインドセットを持つ人々を奨励します
• DevOpsチームを認識します