developers · Oct 1, 2019
ヒーローになろう：Quire APIで自分だけのアプリを作る
最終更新：2026年5月28日
TL;DR： Quire OAuth 2.0 APIを使えば、ユーザーのパスワードを保存することなく、アプリがユーザーのQuireアカウントの代理として動作できます。必要なのは、登録済みのOAuthアプリ（クライアントID、シークレット、リダイレクトURL）、4ステップの認可フロー（設定、リダイレクト、レスポンス処理、コードとトークンの交換）、そしてアクセストークンが1時間で失効するためのリフレッシュトークンのループです。
ユーザーのQuireデータを読み書きするアプリを作るとき、最初に決めるべきは「ユーザーのパスワードを一切見ずにどう認証するか」です。Quire APIはその答えをOAuth 2.0で提供します。本記事では、OAuthアプリのセットアップ、4ステップの認可フロー、アクセストークンとリフレッシュのループ、そして最初の実装で開発者がよく間違えるポイントを順に見ていきます。
Quire OpenAPIの1.0.0リリースは2019年10月に登場し、それ以降安定して稼働しています。OAuthを使うことで、ユーザーはアプリに自分のQuireコンテンツ（タスク、プロジェクト、コメント、担当、タグ、期限の日）へのアクセスを認可でき、あなたは認証情報に一切触れません。ユーザーはパスワードを変更することなく、いつでもそのアクセスを取り消せます。OAuthが普及する前にパスワードを保存する連携がセキュリティ的に問題視されていたのは、まさにこのためです。
どのQuire連携方法があなたのユースケースに合いますか？
OAuth APIを組み込む前に、APIが本当に適切なツールかを確認しておきましょう。2026年現在、Quireには4つの公式な連携手段があり、それぞれ解決する課題が異なります。
| やりたいこと | 使うもの | 理由 |
|---|---|---|
| 自作のアプリでユーザーの代わりにQuireのデータを読み書きする | Quire OAuth API（本記事） | ユーザー認可、フルCRUDアクセス、ポーリング不要 |
| Quire内のイベント（タスク作成、状態変更、コメント追加など）に反応する | Quire Webhook | プッシュ型でポーリングのオーバーヘッドがなく、軽量にセットアップ可能 |
| QuireをClaudeなどのAIエージェントに接続する | Quire MCPサーバー | LLMツール向けの標準プロトコル、構築済みサーバー付属 |
| Quireを自動化やBIワークフローに取り込む | OAuth API＋n8nまたはPower BI | 既成のパイプラインを活用でき、独自実装が少なくて済む |
典型的なアプリ連携（モバイルアプリ、Webダッシュボード、同期サービス）を作るなら、OAuth APIが最適です。本記事ではその前提で話を進めます。
Quire API用のOAuthアプリはどう設定しますか？
Quire APIを使うには、まずOAuthアプリを作成する必要があります。
Quire OAuthアプリを作成する
アプリを作成するには、Quireアカウントにログインしている必要があります。
Quireの開発者アプリコンソールにアクセスし、新しいアプリを作成 ボタンをクリックします。
アプリが所属するQuireの組織を選びます。選択した組織のメンバーは、その組織に属するすべてのアプリを閲覧・編集できます。
アプリ名とリダイレクトURLを入力します。リダイレクトURLの役割は後ほど説明します。ひとまず次のURLを指定してください：
http://localhost:3000/callback新しいアプリを作成 ボタンをクリックすると、新規作成したOAuthアプリが開発者コンソールに表示され、追加の設定ができるようになります。
まとめると、次の3つの情報が手元にあるはずです：
- 開発クライアントID： :wJoMEodI4fSSR54pfNwIuIzLnaJ
- 開発クライアントシークレット： eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex
- コールバックURL：
http://localhost:3000/callback
Quire API用の開発環境はどう整えますか？
ステップ1：アプリを設定する
アプリ内に設定情報を保持します。
const clientId = ':wJoMEodI4fSSR54pfNwIuIzLnaJ';
const clientSecret = 'eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex';
const redirectURI = 'http://localhost:3000/callback';
const authorizationUrl = 'https://quire.io/oauth';
const tokenUrl = 'https://quire.io/oauth/token';
const apiUrl = 'https://quire.io/api';ステップ2：ユーザーをQuireのアプリ認可画面にリダイレクトする
認可用のURLを生成し、ユーザーをQuireのOAuthエンドポイントにリダイレクトします。ログイン中のQuireユーザーがあなたのアプリにコンテンツへのアクセスを認可できるWebページが表示されます。
サンプルURL：
https://quire.io/oauth?client_id=your-client-ID&redirect_uri=your-redirect-uri認可リンクを表示するコードの例：
var http = require('http');
var url = require('url');
var server = http.createServer(function (req, res) {
var uri = url.parse(req.url, true);
if (uri.pathname == '/') {
//..
} else if (uri.pathname == "/install") {
var authUrl = authorizationUrl
+ '?client_id=' + clientId
+ '&redirect_uri=' + encodeURIComponent(redirectURI);
res.writeHead(200, { 'Content-Type': 'text/html' });
res.write(
'<html><body>'
+ '<a href="' + authUrl + '">Connect Quire</a>'
+ '</body></html>');
res.end();
} else if (uri.pathname == "/callback") {
//...
}
});
server.listen(3000);state パラメーターは、クロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐためのランダムな文字列です。ランダムな文字列を生成してください。これはステップ3でアプリにそのまま返されます。アプリはこの値を検証する必要があります。任意のパラメーターではありますが、必ず含めることを強く推奨します。
サンプルURL：
https://quire.io/oauth?client_id=your-client-ID&redirect_uri=your-redirect-uri&state=lpcl9v94zステップ3：OAuth 2.0サーバーのレスポンスを処理する
OAuth 2.0サーバーは、アプリのアクセス要求に対して redirect_uri で指定されたURLを使って応答します。
ユーザーがアクセス要求を承認すると、レスポンスには認可コードが含まれます。承認しなかった場合は、エラーメッセージが含まれます。Webサーバーに返される認可コードまたはエラーメッセージは、次のようにクエリ文字列として渡されます：
エラーレスポンスの例：
http://localhost:3000/callback?error=access_denied認可コードレスポンスの例：
http://localhost:3000/callback?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7コールバック処理の例：
//...
} else if (uri.pathname == "/callback") {
var result = uri.query;
var message = 'Auth fail';
if (result["error_description"] != null) {
message = result["error_description"];
if (result["error"] == 'access_denied') {
//display reject message
}
messageView(res, message);
} else if (result["code"] != null) {
return exchangeAccessToken(result["code"])
.then(function(data) {
var token = data['access_token'];
message = token != null ? 'Success': 'Fail';
messageView(res, message);
});
}
}ユーザーがアプリの redirect_uri にリダイレクトされる際、クエリ文字列パラメーターには code と state も含まれます。state はCSRF対策のトークンとして、リクエストを検証するために使います。
クエリ文字列から code と state を取り出します。この時点で state を検証できます。
検証コードの例：
} else if (result["code"] != null) {
if (result["state"] != stateFromSession(res))
return messageView(res, 'invalid state');
return exchangeAccessToken(result["code"])
.then(function(data) {
var token = data['access_token'];
message = token != null ? 'Success': 'Fail';
messageView(res, message);
});
}ステップ4：認可コードをアクセストークンに交換する
取得した認可コードと以下のリクエストパラメーターを使って、トークンエンドポイントに POST リクエストを送ります。
| パラメーター | 値 |
|---|---|
| grant_type | authorization_code |
| code | {your-authorization-code} |
| client_id | {your-client-ID} |
| client_secret | {your-client-secret} |
| redirect_uri | ステップ2で redirect_uri を指定した場合は必須。値はそこで使ったものと完全に一致している必要があります。 |
アクセストークンを要求するコードの例：
var request = require('request');
function exchangeAccessToken(code) {
return new Promise(function(resolve, reject){
request.post({
url: tokenUrl,
form: {
grant_type: 'authorization_code',
code: code,
client_id: clientId,
client_secret: clientSecret,
redirect_uri: redirectURI
}
},
function (error, httpResponse, body) {
if (error) {
return reject(error);
}
resolve(JSON.parse(body))
});
});
}レスポンスとして受け取るアクセストークンはJSON形式です。
レスポンス例：
{
"access_token":"ACCESS_TOKEN",
"token_type": "bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN"
}このトークンは、Quire APIのすべての呼び出しに必要となるため、安全かつ恒久的に保管してください。
Quireアクセストークンを使ってAPIを呼び出すには？
これでアプリはアクセストークンを手にしたので、ユーザーの代理としてAPIを呼び出せます。
APIを呼び出す
リクエストヘッダーにbearerトークンとしてアクセストークンを付与し、APIを呼び出します。
API呼び出しの例：
function getCurrentUser(token) {
return new Promise(function(resolve, reject){
request.get({
url: apiUrl + '/user/id/me',
headers: {
"Authorization": "Bearer " + token
}
},
function (error, httpResponse, body) {
if (error) {
return reject(error);
}
resolve(JSON.parse(body))
});
});
}レスポンス例：
{
"email": "john@gmail.cc",
"website": "https://coolwebsites.com",
"id": "My_ID",
"description": "This is *cool*!",
"url": "https://quire.io/u/My_ID",
"nameText": "My Name",
"nameHtml": "My Name",
"descriptionText": "This is cool!",
"descriptionHtml": "This is <i>cool</i>!",
"image": "https://quire.s3.amazonaws.com/oid/image.jpg",
"iconColor": "37",
"name": "My Name",
"oid": "Dyh2YkFcu9uLgLFIeN1kB4Ld"
}失効したQuire APIアクセストークンはどう更新しますか？
アクセストークンは意図的に短期間のみ有効に設計されています。これはOAuth 2.0の重要なセキュリティ機構です。Authorization Code Grant Flowを使う場合、アクセストークンの有効期限はデフォルトで1時間です。
アクセストークンが失効すると、HTTP 401エラーが返ります：
{
code: 401,
message: 'Invalid or expired token.'
}
Your application will need to refresh the access token.
function refreshToken(refreshToken) {
return new Promise(function(resolve, reject){
request.post({
url: tokenUrl,
form: {
grant_type: 'refresh_token',
refresh_token: refreshToken,
client_id: clientId,
client_secret: clientSecret
}
},
function (error, httpResponse, body) {
if (error) {
return reject(error);
}
resolve(JSON.parse(body))
});
});
}あるいは、ユーザーを再度認証フローにリダイレクトすることもできます。
Quire APIでよくある実装ミスは何ですか？
Quire APIを使った開発を多くのチームで見てきた中で、同じ5つの問題が繰り返し起こります。どれも分かりにくいものではなく、すべて避けられるものです。
1. クライアントシークレットをクライアント側のコードに保存する。 クライアントシークレットは、その名のとおり「秘密」です。モバイルアプリのバイナリやブラウザのバンドルに含まれてしまえば、誰でも抽出してあなたのアプリになりすませます。シークレットは自分が管理するサーバー上だけに置いてください。アプリが完全にクライアントサイド（SPAやモバイルアプリ）の場合は、シークレットを埋め込まずにOAuth 2.0 PKCEフローを使いましょう。
2. stateパラメーターの検証を忘れる。 state パラメーターはCSRF攻撃を防ぐために存在します。コールバックで検証をスキップすると、悪意あるサイトがユーザーのQuireアカウントを攻撃者のアプリセッションにこっそり結びつけられる穴を残すことになります。リクエストごとに state を生成し、セッションに保存し、返却された state と一致しないコールバックは拒否してください。
3. アクセストークンを永続的なものとして扱う。 アクセストークンは1時間で失効します。トークンを保存したまま更新しないアプリは、初日は問題なく動きますが、2日目には何の警告もなく壊れます。リフレッシュトークンのループは、「ユーザーから苦情が出たら対応するパッチ」ではなく、リリース前に必ず組み込んでおきましょう。
4. APIを変更検知のためにポーリングする。 ポーリングはレート制限、レイテンシー、バッテリーを浪費します。Quire内の変更に反応したい場合は、代わりにWebhookを使いましょう。Webhookはイベントを即座にあなたに届けるので、それを検知するためのAPI呼び出し自体が不要になります。
5. リダイレクトURLの許可リストを設定しない。 OAuthアプリの登録ではリダイレクトURLのリストを設定できます。これをワイルドカードにしたり厳密に設定しなかったりすると、攻撃者は自分のコールバックをあなたのリダイレクト先として登録し、認可コードを横取りできてしまいます。アプリが実際に使う正確なURLだけを登録してください。
初めてAPIで実装するなら、パターンを学ぶ一番の近道は、n8nコネクタのような既存の連携をフォークし、認証・更新・エラー処理の仕組みを読み解くことです。
Quire APIが適さない場面は？
別の連携手段に切り替えるべき3つのパターンを紹介します。
- 状態の取得ではなくイベントへの反応だけが必要な場合。 Webhookはよりシンプルなプッシュ型で、読み取り専用のイベント購読にはユーザー認可も不要です。「何かが起きたら通知して」が目的なら、APIではなくWebhookを使いましょう。
- ClaudeなどLLMエージェントとの連携を作る場合。 Quire MCPサーバーが最適です。認証を処理し、標準スキーマを提供するため、自分でOAuthのコードを書く必要がありません。MCPはこの用途に特化しており、OAuth APIで自前実装するのは同じ結果のために余計な手間をかけることになります。
- 一度限りのデータエクスポートをする場合。 プロジェクトのデータを分析やバックアップ目的で一度だけ取り出したいなら、n8n連携や手動のCSVエクスポートで、1週間分の開発時間を節約できます。
これらのいずれにも当てはまらないなら、OAuth APIがあなたのツールです。
よくあるご質問
Quire APIの利用には有料のQuireプランが必要ですか？
いいえ。Quire APIはFreeプランを含むすべてのプランで利用できます。レート制限はすべてのプランに適用されます。現在のアプリごとの上限についてはAPIドキュメントをご確認ください。
Quire APIはどのプログラミング言語に対応していますか？
APIはHTTPベースで、リクエスト・レスポンスのボディはJSONです。そのため、HTTPクライアントとJSONパーサーを備える言語ならどれでも動作します。本記事の例はJavaScriptですが、同じフローはPython、Go、Ruby、PHP、その他どの言語でも同様に動きます。公式クライアントライブラリは提供していません。APIの規模が小さく、各言語のHTTPクライアントに薄いラッパーを書くのが一般的なパターンだからです。
Quireのアクセストークンはどのくらい有効ですか？
アクセストークンの有効期限はデフォルトで1時間です。リフレッシュトークンはより長く有効で、ユーザーへの再認可なしに新しいアクセストークンを取得するために使えます。リフレッシュトークンのループは初日からアプリに組み込んでください。
Quire APIを読み取り専用で使えますか？
はい。OAuthスコープを使えば、アプリに必要な権限だけを要求できます。タスクを読み取るだけのアプリなら、読み取りスコープのみを指定してください。Quireのユーザーは認可ページで要求されているスコープを確認でき、過剰だと感じれば拒否できます。そのため、必要以上に要求すると承認率が下がります。
Quire APIとQuire MCPサーバーの違いは何ですか？
APIは、ユーザーの代わりにQuireのデータを読み書きしたいあらゆるアプリ向けの汎用的なRESTインターフェースです。MCPサーバーはClaudeをはじめとするLLMエージェント向けに特化されており、認証を処理し、標準的なツールスキーマを公開するため、自分でOAuthのコードを書く必要がありません。従来型のアプリ連携にはAPIを、LLMエージェント連携にはMCPを使ってください。
次のステップは？
以上が、Quire API向けのOAuth 2.0フローの全体像です。OAuthアプリのセットアップ、4ステップの認可、アクセストークンの利用、そしてリフレッシュのループ。開発者が「動く連携をリリースしたのに2日後に壊れる」最大の原因は、リフレッシュのループを後回しの修正として扱い、初日から組み込まないことにあります。
Quireの開発者アプリコンソールから始めるか、APIリファレンスを確認してください。OAuthのコードを一切書きたくないなら、Quire MCPサーバーが認証を肩代わりしてくれます。LLMエージェント連携にはこちらが最適です。イベント駆動の連携であれば、初めてのAPI実装で陥りがちなポーリングよりもWebhookの方がたいてい適切です。
