Haskellのログ出力でやりがちな失敗とは？純粋性を壊さないための正しい設計

Haskellにおけるログ出力は、一見すると単なる副次的な処理に見えますが、実際には設計を誤ると純粋性の破壊や予測不能な挙動につながる重要なポイントです。
特に命令型言語の感覚のまま「とりあえずログを出す」という発想で実装してしまうと、IOアクションが関数の内部に散在し、参照透過性が失われる典型的な失敗パターンに陥ります。

Haskellでは関数の純粋性がシステム全体の推論可能性を支えているため、ログ出力の扱いは単なる技術的選択ではなく設計上の意思決定になります。
例えば、IOモナドを安易に関数内部へ埋め込むとテスト容易性が下がり、依存関係も不透明になります。
一方でWriterモナドや構造化ログの導入を適切に行えば、計算と副作用を分離しつつログを保持することが可能です。

本記事では、Haskellでやりがちなログ出力の失敗例を整理しながら、純粋性を維持したまま観測可能性を確保する設計手法について論理的に解説します。
特に以下のような観点を中心に扱います。

IOの局所化と境界設計の重要性
Writerモナドによるログ収集の利点と限界
実務で使われる構造化ログ設計の考え方

「ログは必要だが副作用は抑えたい」という一見矛盾した要求をどう扱うかは、関数型プログラミングにおける設計力そのものを問うテーマです。
単なる実装テクニックではなく、抽象化と責務分離の問題として整理していきます。

Haskellのログ出力でよくある失敗パターンと設計ミス
純粋性と副作用の基礎：Haskellにおける設計原則
IOモナドにログ処理を直接書くことの問題点
Writerモナドを使ったログ設計の基本とメリット
参照透過性を維持するログ設計の考え方
実務で使われる構造化ログ設計と運用のベストプラクティス
テスト容易性を高めるためのログ分離アーキテクチャ
ログ設計におけるパフォーマンスとトレードオフの考察
まとめ：Haskellにおける正しいログ設計と純粋性の維持

Haskellのログ出力でよくある失敗パターンと設計ミス

Haskellにおけるログ出力は、単なるデバッグ支援の仕組みとして軽視されがちですが、実際にはシステム全体の設計品質に直結する重要な要素です。
特に関数型プログラミングの前提である純粋性を崩してしまうと、コードの予測可能性やテスト容易性が著しく低下します。
そのため、ログ設計における失敗パターンを理解することは、実務的にも理論的にも非常に重要です。

まず典型的な失敗として挙げられるのが、IOアクションの過剰な埋め込みです。
命令型言語の感覚のまま関数内部にputStrLnやファイル書き込み処理を直接記述してしまうと、関数の参照透過性が失われます。
この状態では同じ入力に対して同じ出力を保証できなくなり、関数の再利用性やテストの信頼性が低下します。
特に以下のような構造は問題になりやすいです。

process x = do
  putStrLn "processing..."
  return (x * 2)

このような設計は一見シンプルですが、処理と副作用が混在しているため、関数の本質的な役割が曖昧になります。

次に多いのが、ログ出力をあらゆる層に分散させてしまう設計です。
ビジネスロジック層、データアクセス層、ユーティリティ層のすべてにログが散在すると、システム全体の責務分離が崩壊します。
結果として、ログの形式変更や出力先変更が複数箇所に波及し、保守性が大幅に悪化します。

また、例外処理とログ出力を混同する設計も問題です。
エラー発生時にその場でログを出力する実装は短期的には分かりやすく見えますが、エラー処理の責務と観測の責務が混ざるため、抽象度が不整合になります。
理想的には、エラーの生成とログの記録は分離されるべきです。

失敗パターンを整理すると、以下のように分類できます。

パターン	問題点	影響
IOの直接埋め込み	純粋性の破壊	テスト困難・再利用性低下
ログの分散配置	責務の分裂	保守性の低下
例外とログの混同	抽象度の崩壊	設計の不整合

さらに見落とされがちなのが、ログを「副作用の悪」として過剰に排除しようとする設計です。
Haskellでは純粋性が重要視されるため、ログ自体を避ける設計に偏るケースがありますが、これは現実的ではありません。
システムは必ず観測可能性を必要とするため、ログを完全に排除するのではなく、適切に制御された副作用として扱う必要があります。

この観点で重要になるのが「境界設計」です。
すなわち、純粋な計算部分とIOを扱う部分を明確に分離し、ログ出力は境界層に限定するという考え方です。
この設計により、内部ロジックは純粋性を維持しつつ、外部とのやり取りだけが副作用として扱われます。

結果として、ログ設計は単なる技術的な問題ではなく、アーキテクチャ全体の品質を左右する設計課題になります。
特にHaskellのような関数型言語では、この境界をどれだけ明確に設計できるかが、コードの健全性を決定づける要因となります。

純粋性と副作用の基礎：Haskellにおける設計原則

Haskellの設計思想を理解するうえで最も重要な概念が純粋性（purity）と副作用の分離です。
純粋性とは、同じ入力に対して常に同じ出力を返す性質を指し、この性質によってプログラムの振る舞いは数学的関数として扱えるようになります。
つまり、コードは「実行してみないと分からない処理」ではなく、「推論可能な関数の集合」として扱えるわけです。

この前提が成立することで、Haskellでは以下のような利点が得られます。

参照透過性による推論可能性の向上
テストの容易化
並列実行時の安全性向上

一方で、現実のプログラムではファイル操作やログ出力、ネットワーク通信といった副作用が不可避です。
これらを無視して完全な純粋性だけでシステムを構築することはできません。
そのためHaskellでは、副作用を「IO」として明示的に分離し、型レベルで管理する設計になっています。

副作用の扱いを理解するために、まず純粋関数と副作用を持つ関数の違いを整理します。

種類	特徴	例
純粋関数	入力と出力のみで完結	`f x = x + 1`
副作用あり	外部状態に依存または変更	ログ出力・ファイル書き込み

純粋関数は時間や環境に依存しないため、関数単体での推論が可能です。
一方で副作用を持つ処理は、実行タイミングや外部環境によって結果が変化するため、厳密な意味での関数とは性質が異なります。

Haskellではこの問題を解決するために、IO型を導入しています。
IO型は「副作用を伴う計算」を型として明示的に包み込み、純粋な世界と副作用の世界を分離します。
例えば以下のように扱われます。

main :: IO ()
main = do
  putStrLn "Hello"

このコードではputStrLnが副作用を持ちますが、それはIOコンテキストの中に閉じ込められています。
この構造により、純粋な関数と副作用を持つ処理が混在せず、設計上の境界が明確になります。

重要なのは、Haskellにおける設計原則が「副作用を排除すること」ではなく、「副作用を制御可能な形で隔離すること」にある点です。
この違いを理解していないと、ログ出力のような必要不可欠な機能まで不適切に排除してしまう設計に陥ることがあります。

特にログは典型的な副作用ですが、システムの観測性を担保するためには必須の要素です。
そのため設計上は以下のような方針が重要になります。

純粋関数の内部では副作用を発生させない
副作用はIO境界に集約する
副作用の結果をデータとして扱う

この考え方により、システム全体は「純粋な計算レイヤ」と「副作用を扱うレイヤ」に分離されます。

この分離構造が成立すると、コードは単なる実装ではなく、意味論的に安定したモデルとして扱えるようになります。
結果として、変更に強く、推論可能で、テストしやすい設計が実現されます。
Haskellの設計原則は単なる言語仕様ではなく、ソフトウェア設計そのものに対する一つの厳密な回答と言えます。

IOモナドにログ処理を直接書くことの問題点

Haskellにおいてログ出力を実装する際、最も直感的でありながら同時に問題を引き起こしやすいのが、IOモナド内部に直接ログ処理を記述する方法です。
一見すると「IOの中で副作用を扱っているのだから正しい設計」に見えますが、実際にはこのアプローチには構造的な欠陥が潜んでいます。

まず第一に問題となるのは、関数の責務が曖昧になる点です。
IOモナド内にロジックとログ出力を混在させると、関数が「計算を行う役割」と「観測情報を出力する役割」の両方を担うことになります。
この状態は単一責任原則の観点からも望ましくなく、結果としてコードの理解コストが増大します。

例えば以下のような実装は典型的な問題例です。

processUser :: User -> IO User
processUser user = do
  putStrLn "processing user..."
  let updated = user { active = True }
  putStrLn "done"
  return updated

このコードでは処理自体は単純ですが、ログがロジックの途中に散在しているため、処理の本質が埋もれてしまいます。
特に規模が大きくなると、ログの意図とビジネスロジックの境界が不明瞭になります。

次に問題となるのは、テスト容易性の低下です。
IOモナドに直接ログを埋め込むと、関数は副作用を前提とした形になるため、純粋関数としてテストすることが困難になります。
通常、純粋関数であれば入力と出力のみを検証すればよいですが、IOが絡むことで標準出力のモックや副作用の制御が必要になります。

この結果として以下のような問題が発生します。

単体テストが複雑化する
モック依存が増える
テストの意図が不明確になる

特にCI環境においては、IO依存のテストは実行時間や安定性にも影響を与えるため、設計段階での回避が重要になります。

さらに見逃されがちな問題として、ログの構造化が困難になる点があります。
IOモナド内で単純に文字列としてログを出力してしまうと、ログは非構造的なデータとして蓄積されます。
その結果、後から分析や検索を行う際に柔軟性が失われます。

構造的な観点で整理すると以下のようになります。

設計方式	ログの扱い	問題点
IO直書き	文字列出力	構造化不可
純粋関数 + IO混在	分散ログ	追跡困難
分離設計	データとして保持	実装コスト増だが拡張性高い

また、IOモナド内にログ処理を埋め込む設計は、再利用性の低下にも直結します。
例えば、同じビジネスロジックをバッチ処理とAPI処理の両方で利用したい場合、ログ出力が混在していると環境ごとの制御が困難になります。
結果としてコードの再利用が制限され、重複実装が発生する原因になります。

本質的な問題は、IOモナドそのものではなく、「IOの使い方」にあります。
IOは副作用を扱うための正しい仕組みですが、それを無秩序に関数内部へ持ち込むことで、設計上の境界が破壊されます。

したがって重要なのは、IOを使うかどうかではなく、どの粒度でIOを扱うかという設計判断です。
ログ出力をIOの内部に直接書くのではなく、境界層に押し出し、純粋なロジックと分離することが、長期的に見て最も保守性の高い設計となります。

Writerモナドを使ったログ設計の基本とメリット

Haskellにおけるログ設計を改善するうえで、IOモナドに直接依存する実装から脱却する手段として有力なのがWriterモナドの活用です。
Writerモナドは「計算結果」と「付随情報（ログなど）」を同時に扱うための抽象化であり、副作用を関数の外側に明示的に分離しながらログを収集できるという特性を持ちます。

このアプローチの本質は、ログ出力を「実行時の副作用」ではなく「計算結果に付随するデータ」として扱う点にあります。
これにより、ログは実行時に即座に出力されるのではなく、関数の戻り値として蓄積され、後から一括で処理できるようになります。

Writerモナドの基本構造を理解するために、まず簡単な例を示します。

import Control.Monad.Writer
type Log = [String]
process :: Int -> Writer Log Int
process x = do
  tell ["input: " ++ show x]
  let result = x * 2
  tell ["result: " ++ show result]
  return result

このコードではtellを使ってログを追加していますが、重要なのはこの時点ではまだIOが発生していないという点です。
すべてのログはWriter内部に蓄積され、最終的にrunWriterによってまとめて取り出されます。

Writerモナドを用いることで得られるメリットは複数ありますが、特に重要なのは以下の3点です。

純粋関数のままログを扱える
テスト時に副作用を排除できる
ログの構造化が容易になる

これにより、従来IOモナド内に散在していたログ処理を関数の外側に移動でき、関数の責務を「計算」に限定できます。

設計観点から見ると、Writerモナドは「計算と観測の分離」を自然に実現する仕組みです。
従来のIOベースのログ設計では、観測行為そのものが計算と混在していましたが、Writerモナドではログは単なる蓄積データとして扱われるため、関数は副作用から解放されます。

この違いを整理すると以下のようになります。

観点	IO直接ログ	Writerモナド
副作用の扱い	実行時に発生	データとして蓄積
テスト容易性	低い	高い
ログ構造化	困難	容易
純粋性	破壊されやすい	維持される

また、Writerモナドのもう一つの重要な利点は、ログの合成が自然に行える点です。
複数の関数がそれぞれログを返した場合でも、モナドの結合則によってログは自動的に連結されます。
これにより、ログ集約のための手続き的なコードを書く必要がなくなります。

この特性は大規模な処理パイプラインにおいて特に有効であり、各処理ステップが独立したログを持ちながらも、最終的には一貫したログストリームとして統合されます。

ただしWriterモナドにも限界は存在します。
例えば、大量ログを扱う場合にはメモリ効率の問題が発生する可能性があります。
また、リアルタイムログ出力が必要なシステムでは適用が難しいケースもあります。
そのため実務では、Writerモナドは「設計初期段階の抽象化」や「テスト用ログ収集」として利用されることが多いです。

結論として、Writerモナドはログを副作用ではなくデータとして扱うことで、Haskellの純粋性を維持しながら観測可能性を確保するための強力な設計手段です。
ただし万能ではなく、用途に応じてIO境界との適切な分離設計を行うことが重要になります。

参照透過性を維持するログ設計の考え方

Haskellにおけるログ設計を議論する際、中心的な概念となるのが参照透過性（referential transparency）です。
これは「同じ入力に対して常に同じ出力を返す」という性質であり、関数型プログラミングの理論的基盤を支えています。
ログ出力のような副作用を扱う場合、この性質をどのように維持するかが設計の核心となります。

参照透過性が損なわれる典型的な状況は、関数の内部で直接ログ出力を行うケースです。
例えば、標準出力への書き込みやファイルへの追記は、外部状態に依存するため関数の振る舞いを非決定的にしてしまいます。
この状態では、同じ関数呼び出しであっても実行タイミングや環境によって結果が変化し得るため、純粋関数としての性質が崩壊します。

この問題を解決するためには、ログを「副作用として実行するもの」ではなく「関数の戻り値に付随するデータ」として扱う必要があります。
つまり、ログを計算結果と同列のデータ構造として扱い、外部への出力は関数の外側で行う設計にすることが重要です。

この考え方を形式化すると、関数は次のように分解できます。

純粋な計算部分：入力 → 出力 + ログデータ
副作用実行部分：ログデータ → IO出力

この分離により、参照透過性は計算部分に限定して維持されることになります。

具体的な設計パターンとしては、以下のような構造が一般的です。

層	役割	参照透過性
ドメイン層	純粋計算とログ生成	維持される
アプリケーション層	ログ収集と統合	条件付き
IO境界層	実際の出力処理	非純粋

このように層を分離することで、参照透過性はドメイン層に限定して保証され、システム全体としての設計の健全性が保たれます。

Haskellではこの設計を実現するために、WriterモナドやIOの遅延評価的な扱いが用いられますが、重要なのはツールそのものではなく設計思想です。
すなわち、「ログは観測結果であり、計算そのものに影響を与えない」という原則を徹底することです。

この原則が守られている限り、ログは関数の入力にも出力にも影響しないため、参照透過性は維持されます。

ここで注意すべき点として、ログを過度に抽象化しすぎると実用性が損なわれる可能性があります。
例えば、リアルタイム性が要求されるシステムでは、ログは即時出力される必要があり、純粋性とのトレードオフが発生します。
この場合は、純粋性を保つ領域とIOを許容する領域の境界設計がより重要になります。

最終的に重要なのは、参照透過性を絶対的な制約として捉えるのではなく、「どの範囲で保証するか」を設計として明示することです。
Haskellの強みは、この境界を型レベルで表現できる点にあり、ログ設計においてもその恩恵を最大限活用することが求められます。

実務で使われる構造化ログ設計と運用のベストプラクティス

実務におけるログ設計は、単なるデバッグ支援を超えて、システムの可観測性（observability）を支える中核的な要素です。
特にHaskellのような関数型言語では、純粋性を維持しながら運用可能なログ基盤を構築する必要があり、そのためには構造化ログの設計思想が重要になります。

構造化ログとは、単なる文字列出力ではなく、キーと値のペアとして情報を記録する形式を指します。
この形式にすることで、ログは人間だけでなく機械的な解析にも適したデータ構造となり、検索性や集計性が大幅に向上します。

まず実務でよく採用されるログ設計の基本方針を整理します。

ログは必ず構造化データとして出力する
重要なコンテキスト情報（ユーザーID、リクエストIDなど）を必ず含める
ログレベルを明確に分類する（INFO / WARN / ERRORなど）
出力と生成を分離し、ロジック層から直接出力しない

これらの原則は、システム規模が大きくなるほど重要性を増します。
特に分散システムでは、単一ノードのログだけでは全体像を把握できないため、構造化と相関IDの設計が不可欠になります。

構造化ログの具体例としては、以下のようなJSON形式が一般的です。

{
  "level": "INFO",
  "message": "user processed",
  "userId": 42,
  "requestId": "abc-123",
  "durationMs": 15
}

このような形式にすることで、ログは単なるテキストではなく分析可能なデータセットになります。
例えばELKスタックやDatadogなどのログ基盤では、この構造化情報をもとに検索・可視化・アラート設定が可能になります。

Haskellにおける設計では、この構造化ログを純粋関数の戻り値として扱い、IO境界でのみ出力する設計が推奨されます。
これにより、ドメインロジックは副作用から完全に分離され、テスト容易性が維持されます。

実務的なアーキテクチャを整理すると以下のようになります。

層	責務	ログの扱い
ドメイン層	ビジネスロジック	ログデータ生成のみ
サービス層	処理統合	ログ集約
インフラ層	外部出力	ログ送信

さらに運用面では、ログの「粒度設計」が極めて重要です。
過剰なログはストレージコストとノイズを増加させ、逆に不足すると障害解析が困難になります。
そのため、以下のような観点でバランスを取る必要があります。

エラー発生時は必ず詳細ログを出力する
通常処理では必要最小限の情報に留める
パフォーマンス影響を考慮してログレベルを動的制御する

また、分散環境ではトレースIDの導入がほぼ必須になります。
複数サービスをまたぐリクエストの流れを追跡するために、各ログに共通の識別子を付与することで、システム全体の因果関係を再構築できます。

最終的に重要なのは、構造化ログを単なる出力形式ではなく「設計の一部」として扱うことです。
Haskellのような強い型システムを持つ言語では、ログもまたデータとして厳密に定義し、型安全な形で扱うことで、システム全体の信頼性を高めることができます。

テスト容易性を高めるためのログ分離アーキテクチャ

Haskellにおけるログ設計を実務レベルで考える際、見落とされがちだが極めて重要な観点が「テスト容易性」です。
ログ出力がビジネスロジックに密結合している場合、単体テストは副作用の影響を受けやすくなり、検証対象が不明瞭になります。
そのため、ログを適切に分離するアーキテクチャ設計が不可欠になります。

基本的な考え方は単純で、ロジックとログを同一の実行コンテキストに置かないことです。
これにより、テスト対象の関数は純粋性を維持し、入力と出力のみで振る舞いを検証できるようになります。

まず、テスト容易性が低い典型的な設計を整理します。
IOモナド内に直接ログ出力を埋め込む場合、関数は外部環境に依存するため、テスト時に副作用の制御が必要になります。
この状態では以下の問題が発生します。

標準出力のモックが必要になる
ログ内容の検証が困難になる
テストの再現性が低下する

このような設計は、テストコード自体の複雑性を増加させ、本来のロジック検証という目的を曖昧にします。

一方で、ログ分離アーキテクチャでは、関数はログを直接出力せず、ログ情報をデータとして返却します。
これにより、テスト対象は純粋関数となり、副作用は完全に排除されます。

この設計を整理すると以下のような構造になります。

層	責務	テスト観点
ドメイン層	純粋計算 + ログ生成	入出力のみ検証
アプリ層	ログ収集・統合	データ構造検証
IO層	外部出力	統合テスト対象

具体的な設計思想として重要なのは、「ログは戻り値の一部である」という認識です。
これにより、関数は次のような形に変わります。

入力：ドメインデータ
出力：結果 + ログデータ

この構造により、テスト時にはログを含めた完全な出力構造を検証することが可能になります。

また、テスト容易性を高めるためには依存性の方向も重要です。
依存関係を以下のように整理することで、テスト対象の範囲を明確にできます。

ドメイン層は他層に依存しない
ログ出力はインフラ層に閉じる
アプリケーション層は両者を接続するのみ

この依存方向の制御により、テストはドメイン層に集中できるようになり、テストの純度が高まります。

さらに実務では、ログ分離アーキテクチャは単体テストだけでなく、統合テストやデバッグ効率にも影響を与えます。
特に障害解析時には、ログが構造化されていることで原因特定が容易になり、テスト時に想定されていなかった挙動も追跡可能になります。

重要なポイントは、ログ分離は単なる設計改善ではなく、テスト戦略そのものを変える設計手法であるという点です。
Haskellのような純粋関数型言語では、この設計を徹底することで、テストコードはより数学的な性質を持つ検証へと進化します。

結果として、ログを分離することはテスト容易性の向上だけでなく、システム全体の信頼性向上にも直結します。

ログ設計におけるパフォーマンスとトレードオフの考察

ログ設計をシステム全体の観点から評価する場合、機能性や可観測性だけでなく、パフォーマンスへの影響を無視することはできません。
特にHaskellのような純粋関数型言語では、副作用の制御が厳密である一方、ログ処理をどの層で実行するかによって実行コストやメモリ使用量に明確な差が生じます。

ログは本質的に「追加情報の生成と保存」という処理であり、計算そのものではないため、システムにとってはオーバーヘッドとなります。
このため、設計段階でどの程度の詳細さでログを記録するか、またどのタイミングで出力するかを慎重に決定する必要があります。

まずパフォーマンスに直接影響を与える要因を整理します。

ログの生成頻度
ログの粒度（詳細度）
出力先（標準出力・ファイル・外部サービス）
バッファリングの有無

これらの要素は相互に影響し合い、単純な設計では最適解を導くことが困難です。
例えば、詳細なログを常に出力する設計はデバッグには有用ですが、本番環境ではI/O負荷がボトルネックになる可能性があります。

Haskellにおけるログ設計では、特に「遅延評価」との相互作用に注意が必要です。
ログ生成が遅延評価される場合、評価タイミングが予測しづらくなり、メモリ使用量が一時的に増加することがあります。
これは特にWriterモナドやログ蓄積型設計で顕著になります。

この問題を整理すると、ログ設計には明確なトレードオフが存在します。

観点	高詳細ログ	低詳細ログ
パフォーマンス	低下しやすい	高い
可観測性	高い	低い
メモリ使用量	増加	安定
障害解析性	優れる	制限される

このように、すべての要件を同時に満たすことは不可能であり、システムの目的に応じてバランスを取る必要があります。

また、実務的な観点ではログ出力先も重要な要因になります。
標準出力への書き込みは比較的軽量ですが、外部ログサービスへの送信はネットワーク遅延やシリアライズコストが発生します。
そのため、ログの非同期化やバッチ処理が導入されることが一般的です。

この設計はパフォーマンスを改善する一方で、ログの即時性を損なう可能性があります。
つまり、リアルタイム性と効率性の間にトレードオフが発生します。

さらにHaskell特有の問題として、純粋性とパフォーマンス最適化の衝突も存在します。
純粋関数としてログを扱う場合、すべてのログはデータとして保持されるため、メモリ消費が増加する傾向があります。
一方でIO境界で即時出力する設計ではメモリ効率は改善されますが、純粋性は低下します。

このような背景から、実務では以下のようなハイブリッド設計が採用されることが多いです。

開発環境では詳細ログ + 同期出力
本番環境では簡易ログ + 非同期出力
エラー時のみ高詳細ログを有効化

この設計により、パフォーマンスと可観測性のバランスを動的に調整できます。

最終的に重要なのは、ログ設計を静的なものとして捉えるのではなく、システム運用の文脈で動的に調整可能な要素として設計することです。
Haskellの強力な型システムと純粋性は、こうした設計判断を明確に分離しやすくするための基盤として機能します。

まとめ：Haskellにおける正しいログ設計と純粋性の維持

Haskellにおけるログ設計を体系的に振り返ると、その本質は単なる「出力方法の選択」ではなく、純粋性をどの範囲で維持し、どこから副作用を許容するかという境界設計の問題であることが明確になります。
ログはシステム運用に不可欠な要素である一方で、扱いを誤ると関数型プログラミングの最大の利点である参照透過性を損なう原因にもなります。

これまでの議論で見てきたように、IOモナドへの直接的なログ埋め込みは設計を単純に見せる一方で、責務の混在やテスト容易性の低下を招きます。
一方でWriterモナドや構造化ログの導入は、純粋関数としての性質を維持しながらログを扱うための有力なアプローチとなります。

重要な設計原則を整理すると、Haskellにおけるログ設計は次の三層構造に集約されます。