イスラムの礼拝時刻とキブラ方角を計算|method・高緯度補正対応
日付、緯度・経度、実効UTC offset、標高、PrayTimes互換method、Asr、算術Hijri profile、Makkah delayから、日の入りを含むFajr〜Ishaとキブラ真方位をブラウザー内で計算します。
計算結果
【結果直下の注意】天文式と選択profileによる参考値で、礼拝の宗教的・地域的な公式時刻や方角を確定しません。利用地域のモスク・宗教機関の時刻表と案内を優先してください。
- 礼拝時刻一覧
-
計算すると数値表を表示します。
礼拝時刻一覧。入力した日付・位置・methodに対するFajrからIshaまでの天文計算時刻と補正状態です。 Gregorian日 算術Hijri日(午前0時基準) Fajr 日の出 Dhuhr Asr 日の入り Maghrib Isha 補正・停止状態 - キブラ真方位
- —
- 今回の計算profile
- —
使い方
- 計算日を1900年から2099年の実在する日付から選びます。ページを開いた瞬間の時刻や端末の日付を読み込まず、選んだ1日だけを計算します。
- 経度は東経を正・西経を負、緯度は北緯を正・南緯を負として入力します。日本なら対象日時点の実効UTC offsetに540分を指定し、DSTを含む地域では合算後の差を入力します。
- 地平線に対する観測高を入力し、PrayTimes互換method、Asr profile、午前0時基準の算術Hijri label、Makkah Isha delay 90分または120分を明示選択します。
- 結果ではFajr、日の出、Dhuhr、Asr、日の入り、Maghrib、Ishaを順に確認し、補正状態がnormalかhigh-latitude-adjustedか、またはno-crossingで停止したかを必ず確認します。
- キブラ方位は真北0度から時計回りの球面初期方位です。地域のモスク・宗教機関が公表する礼拝時刻と方角、現地の運用、観測による月初を最終的に優先してください。
計算式・考え方
NOAA/Meeus系の均時差Eと赤緯δを日付から求め、太陽南中=720−4×東経−E+実効UTC offsetとします。指定高度hの交点はcosω=(sin h−sinφ sinδ)/(cosφ cosδ)、時刻差は4ω分です。Fajr/Ishaはmethod角、Asrはatan(1/(影長係数+tan|φ−δ|))、キブラはKaaba基準点への球面大圏初期方位で求めます。
注意事項
- この計算は礼拝を行うべき宗教上の最終時刻を確定するものではありません。同じ都市でもモスク、宗教機関、法学派、採用角度、慎重時間、観測条件によって時刻表が異なるため、実際の礼拝では地域の公表表を優先します。
- Fajrは日の出前の薄明に対応し、MWLは18度、ISNAは15度、Egyptは19.5度など、methodごとに太陽伏角が異なります。数値が大きいほど一般に計算上のFajrは早くなりますが、どの値が宗教的に優れているかを判定しません。
- Ishaもmethodによって角度またはMaghrib後の分数で決まります。Makkahは90分または120分を利用者が明示し、算術Hijri月からRamadanを推定しません。他methodでも入力値をprofileへ残しますが計算には適用しません。
- 高緯度のMakkahでは固定遅延のIsha候補が翌日のFajrへ達する場合があります。このとき新しい宗教的上限や短縮時刻を作らず、Ishaだけを『計算停止』、raw値をnull、statusをstopped-unsupported:makkah-delay-crosses-next-fajrとして残します。翌日Fajrを得られない場合もnext-fajr-unavailableでIshaだけを停止します。
- rawのIsha候補が翌日Fajrよりわずかに早くても、両方を分単位half-upした公開時刻が同じなら利用者には前後関係を確認できません。この場合はoverlaps-next-fajr-minuteとしてIshaだけを停止します。raw交差、公開分重複、Fajr unavailableを別statusにして原因を混同しません。
- JafariとTehran-PrayTimes-compatではMaghribを日の入りと同一にせず、太陽が地平線下4度または4.5度になる夕方交点を使います。Tehran Isha 14度はPrayTimes互換既定で公式Tehran値ではありません。日の入り列とMaghrib列を比較してください。
- Asrのstandardは物体高1倍、hanafiは2倍を正午時点の影へ加えた影長を基準とする角度計算です。影長係数を途中で切り替えて同じ表として扱うと比較条件が崩れるため、選択profileを結果直下にも残します。
- Dhuhrは太陽中心がその地点の子午線を通過する南中時刻です。時計の12時とは限らず、経度、対象日時点の実効UTC offset、均時差によって前後します。宗教機関が安全側の数分を追加する運用はこの天文値に自動加算しません。
- 日の出と日の入りは太陽上辺と標準的な見かけの地平線を近似する0.833度に、観測高hメートルの0.035√h度を加えた伏角で計算します。気圧、気温、湿度、山並み、建物、海面の異常屈折は取得しません。
- 標高入力は地形遮蔽を消すものではありません。高い場所でも周囲に山や建物があれば実見時刻は計算と違います。0〜3000mの有界入力は開けた地平線の簡略モデルであり、登山や航空の安全判断には使えません。
- 緯度は−65度から+65度に限定します。angle-based高緯度補正ではFajrに前日の日の入りから当日の日の出まで、MaghribとIshaに当日の日の入りから翌日の日の出までという別々の夜長を使い、その事実をstatusへ表示します。
- 極昼・極夜などで日の出または日の入り自体が得られない場合は、近隣緯度の値や固定時刻を捏造せずno-crossingとして停止します。停止は0時や空欄とは異なる状態で、利用者が見落とさない文字列として残します。
- 実効UTC offsetは−12時間から+14時間を15分刻みで明示入力します。標準時とDSTを合算した対象日時点の値で、UTC+10:30のような30分差も表現できます。IANA timezone databaseや端末から推測しません。
- DSTを独立した0/60分選択にはしません。30分などの地域差や制度変更を誤排除しないため実効offsetへ統合し、夏時間の開始日・終了日は自動判定しません。利用者が対象日時の有効値を確認します。
- 時刻を分へhalf-up丸めます。内部値が日付境界を越えた場合は『翌日』または『前日』を消さず表示します。丸め後の時刻だけを比較して順序を入れ替えたり、00:00〜23:59へ無条件に折り返したりしません。
- 算術Hijri日はGregorian行の午前0時へ付けるstandard、kuwaiti、fatimid周期則の参考ラベルです。宗教日は前日の日没から始まり、新月の目視や地域の月初宣言とは一致しない場合があります。Makkah delayの分岐には使いません。
- キブラはKaaba基準点への球面上の最短経路について、出発地点での初期方位を返します。平面地図上の直線角度ではなく、真北0度、東90度、南180度、西270度の時計回りです。
- キブラ方位は磁北を補正しません。スマートフォンや磁気コンパスと比べるときは、端末が真北と磁北のどちらを示すか、磁気偏角、金属、電気機器、センサー校正を別に確認してください。
- Kaaba基準点と入力座標が同一点なら初期方位は定義できないためat-reference-pointとして停止します。反対側の対蹠点付近も最短経路が一意にならないため、もっともらしい角度を返しません。
- 基準点21.422487°N、39.826206°EはITRF96/GRS80のversioned geodetic referenceとして固定します。runtimeは球面初期方位を0.1度へ丸めて表示し、楕円体測地・測量・磁北・宗教判断の精度を保証しません。
- NOAAの太陽計算資料は均時差、赤緯、時角、方位の式を照合するための技術資料です。NOAA自身が旧calculatorを現在は保守していない旨を示しているため、現在の公式精度認証サービスとは説明しません。
- JAKIMのJurnal Falakは、地平線近くの大気差がMaghribと日の出の計算へ直接影響し、標準値と実測が異なりうることを示します。このため分単位表示を実際の観測精度の保証にはしません。
- PrayTimesの7 method表は互換定数を固定する実装資料です。各名称の組織が現行値を公式承認したという意味ではありません。dataset id、確認日、選択したFajr・Isha・Maghrib定数を結果profileへ残します。
- Tokyo Camiiの2026年7月公式表では7月17日の各時刻が本engineのMWL推定と一部異なります。これはmethod、慎重時間、施設運用の差を示す実例で、式の正解oracleにはせず、地域のモスク公式表を優先します。
- 入力値と計算はブラウザー内JavaScriptだけで処理し、日付、位置、profileをサーバーへ送信しません。fetch、XMLHttpRequest、WebSocket、geolocation、Cookie、localStorage、外部CDNを使わない設計です。
- 個人宅や非公開施設の正確な座標を入力する必要はありません。市区町村や旅行先の概略座標で足りる用途では不要な桁を減らし、結果を共有するときも位置情報が個人を特定しないか確認してください。
- 1900〜2099年の先発グレゴリオ暦だけを扱います。歴史的な地方時、改暦、日付変更線の行政変更、将来のtimezone制度を再現しません。式の適用範囲と入力境界を一致させるため、範囲外を推定値で埋めません。
- 表示結果は計画や比較の参考です。礼拝の有効性、宗教的義務、断食開始、旅行中の短縮・併合、方角許容範囲などの宗教判断を出力しません。必要な判断は地域の宗教機関や信頼する有資格者へ確認してください。
- 単日ページでは計算条件を結果と切り離さないことが重要です。採用座標、実効UTC offset、標高、method、Asr、Makkah delayを結果summaryへ戻し、時刻だけが独り歩きしにくい構成にします。別表とは同じ条件へ揃えて比較します。
- 計算時刻の前後関係も検算点です。通常はFajr、日の出、Dhuhr、Asr、日の入り、Maghrib、Ishaの順で、sunset型Maghribは日の入りと同時です。engineは越境prefixを保持した絶対分で順序を検査します。
- 参照式とprofileは2026-07-17に確認し、固定dataset praytimes-seven-methods-20260717、engine solar-prayer-time-table-v1、mode single-day-with-qiblaとして保存します。runtime実行時のnetwork取得はありません。
- 【結果直下の注意】天文式と選択profileによる参考値で、礼拝の宗教的・地域的な公式時刻や方角を確定しません。利用地域のモスク・宗教機関の時刻表と案内を優先してください。
よくある質問
同じ場所なのに別の時刻表と数分違うのはなぜですか?
Fajr/Isha角度、Asr影長、慎重時間、標高、大気差、丸め、実効UTC offset、高緯度補正が異なるためです。methodと補正状態を合わせて比較してください。
日本では実効UTC offsetに何を入れますか?
現行の日本標準時は540分(UTC+9)です。海外ではDSTを含め、対象日時点で実際に有効な差を確認してください。
Hijri日が地域のカレンダーと違います。誤りですか?
この列はGregorian日の午前0時基準の算術ラベルです。宗教日は前日日没から始まり、観測月初や公式暦とも方式が違うため一致を保証しません。
MakkahでIshaだけ計算停止になるのはなぜですか?
90/120分後が翌日Fajr以降、公開分がFajrと同一、または翌日Fajrを検証不能のいずれかです。他の有効時刻は保持し、別の宗教的時刻を自動生成しません。
キブラはコンパスの角度と同じですか?
本結果は真北基準の大圏初期方位です。磁北コンパスでは地域の磁気偏角と端末誤差が加わるため、そのまま一致しません。
位置や日付は外部へ送られますか?
送信しません。ブラウザー内の固定式と静的profileだけで最大1行を計算し、現在地や外部APIを使いません。
日付、緯度、経度、実効UTC offset、標高、method、Asr、算術Hijri profile、Makkah Isha delayはclient-onlyで処理します。現在地取得、IP推定、端末timezone、実行時network、外部API、Cookie、localStorage、サーバー保存を使いません。入力値と計算結果はブラウザー内で完結します。